From nobody Wed Sep 1 06:58:45 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6ED3A12D5 for ; Wed, 1 Sep 2021 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 A7VZLzi2XRXE for ; Wed, 1 Sep 2021 06:58:23 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB333A12C4 for ; Wed, 1 Sep 2021 06:58:23 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id z18so5252800ybg.8 for ; Wed, 01 Sep 2021 06:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LHoVjMzS6Bg+C9cuBEiv2+0lnHqnYlNkPgcL2+Npq24=; b=iQxB1N/LZikQ03PYAvBkTQOd9uQWqhrqgeHxNieMb7pSd6wrNwOJzQBig4/ioYxICo 53Vk6ABV2F/CSxiIWyzXoo3ih8chsxv5KUDx7u+pAVhZ9r1fV6K6M/rzSqtgcFYs66mw qvUCUfpqIOfYW26vG5L2SwW/1hnRy5MnbfvsZVHMab1XD3IGlYKvTawdQlX73FnL1pdW pNiV0VQ5nvcVDaFC1nue2nGgLnopdWIKGA5c1cI6ZJdCvutbge8Nu1eHDYDYtd7Vlndq Os+FqvoVl3JCn1DUUB/+z3Iuz/cR5dnGXO4Yx4EKQPFQiHgt6SI38GHdJIW7D6RhlQAW iFSg== 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=LHoVjMzS6Bg+C9cuBEiv2+0lnHqnYlNkPgcL2+Npq24=; b=CU92onQsjG13bLPATAwNAoxoaOw9dkAhQecBExUiCy2XZL99/5z6Mzul667KMlhIKz NWT7vm6eIZTB6imkZM6OVB+oh/enNoHDslJRrA1cNNoJwhfWdLI9GJoXnbQahud6dEjB B0I9g1FLZnCHyv8ECjeR0mH9zvrKnHIPxCzT1PVxpV4U4W2ppyGZ1Ys0WajFRm47yRJm nrF+r/bj/dl0LAOrwaHhJXAmlhW+Iai0i1nlzVjIGFQt9f+7AE0EcA35xXyh5BnJB27i jh2iY9a90gjOGpGla/PKJQmlgM7ExxWA5xtlqtIT5WpaI976HSHH9FmJwUxyrHCkzHsn RfiQ== X-Gm-Message-State: AOAM531YNObD8yKA01eau8tUfJsdxlU8CJ1NsHpY3beW83eZ8kzMaK1Y 4WYE0VhrzHYvtbppwQjp+cqGv/dMbugi+53/xFsfDQitOxQ= X-Google-Smtp-Source: ABdhPJzo2qa3fo5o+tcgOLhuXiJIRqU4nveiZxv5JxwXRdvi1dPNgKZAbCFnLmm4afbb59jlBQBbyfjBnXJRQP9UEiM= X-Received: by 2002:a25:5b06:: with SMTP id p6mr37381393ybb.217.1630504702311; Wed, 01 Sep 2021 06:58:22 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> From: Thomas Broyer Date: Wed, 1 Sep 2021 15:58:11 +0200 Message-ID: To: Justin Richer Cc: IETF oauth WG , mscurtescu@google.com, sdronia@gmx.de, ashvinnarayanan@gmail.com Content-Type: multipart/alternative; boundary="00000000000096031f05caef7500" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Sep 2021 13:58:44 -0000 --00000000000096031f05caef7500 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with you Justin. While there probably is a need for an errata to this RFC wrt public clients, it wouldn't be the one proposed here. Wrt public clients, section 5 states: According to this specification, a client's request must contain a valid client_id, in the case of a public client, or valid client credentials, in the case of a confidential client. but actually nowhere in the specification is defined how a public client would pass its client_id in the request. As an errata, this section should probably be reworded to remove any mention of public clients. And then the RFC should possibly be obsoleted with a new one properly supporting the public clients' use case (and then I would argue just adding a client_id parameter alongside token and token_type_hint) As far as the currently proposed change is concerned, there's no point in accepting as authorization the same access token that would be revoked, as this would be exactly the same, security-wise, as not having authentication at all. On Mon, Aug 23, 2021 at 9:42 PM Justin Richer wrote: > I personally don=E2=80=99t agree with this errata. Token Revocation was n= ever > meant to act as a protected resource, but rather as a function of the AS. > The client is known to the AS and so authentication is expected here. > > =E2=80=94 Justin > > > On Aug 22, 2021, at 5:14 AM, RFC Errata System < > rfc-editor@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC7009, > > "OAuth 2.0 Token Revocation". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6663 > > > > -------------------------------------- > > Type: Technical > > Reported by: Ashvin Narayanan > > > > Section: 2.1 > > > > Original Text > > ------------- > > The client constructs the request by including the following > > parameters using the "application/x-www-form-urlencoded" format in > > the HTTP request entity-body: > > > > token REQUIRED. The token that the client wants to get revoked. > > > > token_type_hint OPTIONAL. A hint about the type of the token > > submitted for revocation. Clients MAY pass this parameter in > > order to help the authorization server to optimize the token > > lookup. If the server is unable to locate the token using > > the given hint, it MUST extend its search across all of its > > supported token types. An authorization server MAY ignore > > this parameter, particularly if it is able to detect the > > token type automatically. This specification defines two > > such values: > > > > * access_token: An access token as defined in [RFC6749], > > Section 1.4 > > > > * refresh_token: A refresh token as defined in [RFC6749], > > Section 1.5 > > > > Specific implementations, profiles, and extensions of this > > specification MAY define other values for this parameter > > using the registry defined in Section 4.1.2. > > > > The client also includes its authentication credentials as described > > in Section 2.3. of [RFC6749]. > > > > For example, a client may request the revocation of a refresh token > > with the following request: > > > > POST /revoke HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > > > > token=3D45ghiukldjahdnhzdauz&token_type_hint=3Drefresh_token > > > > 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. > > > > Corrected Text > > -------------- > > The client calls the revocation endpoint using an HTTP > > POST [RFC7231] request with the following parameters sent as > > "application/x-www-form-urlencoded" data in the request body: > > > > token REQUIRED. The token that the client wants to get revoked. > > > > token_type_hint OPTIONAL. A hint about the type of the token > > submitted for revocation. Clients MAY pass this parameter in > > order to help the authorization server to optimize the token > > lookup. If the server is unable to locate the token using > > the given hint, it MUST extend its search across all of its > > supported token types. An authorization server MAY ignore > > this parameter, particularly if it is able to detect the > > token type automatically. This specification defines two > > such values: > > > > * access_token: An access token as defined in [RFC6749], > > Section 1.4 > > > > * refresh_token: A refresh token as defined in [RFC6749], > > Section 1.5 > > > > Specific implementations, profiles, and extensions of this > > specification MAY define other values for this parameter > > using the registry defined in Section 4.1.2. > > > > The client MUST also include in the request, the access token it > received > > from the authorization server. It must do so in the same way as it > would > > when accessing a protected resource, as describe in [RFC6749], Sectio= n > 7. > > > > The following is a non-normative example request in which the client > uses > > its access token to revoke the associated refresh token: > > > > POST /revoke HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW > > > > token=3D45ghiukldjahdnhzdauz&token_type_hint=3Drefresh_token > > > > The following is a non-normative example request in which the client > uses > > its access token to revoke the same access token: > > > > POST /revoke HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW > > > > token=3DczZCaGRSa3F0MzpnWDFmQmF0M2JW&token_type_hint=3Daccess_token > > > > The authorization server MUST validate the access token used by the > > > client to authorize its call to the revocation endpoint, including > > ensuring that it is not expired or revoked. > > Additionally, the authorization server MUST also validate whether the > > access token used for authorization is part of the same grant as the > > token being revoked. If validation fails, the request is refused and > > the client is informed of the error by the authorization server. > > In the case of a bearer token, the authorization server SHOULD > respond > > with an HTTP 401 code as described in OAuth 2.0 Bearer Token Usage > > [RFC6750], Section 3. > > Errors based on other types of tokens are beyond the scope of this > > specification. > > > > > > Notes > > ----- > > It appears as though the authors of RFC7009 have failed to consider tha= t > requests to revoke are likely to come from non-confidential clients and > such, would lack authentication credentials. Regardless of the type of > client however, authentication should not be required. The OAuth 2.0 > specification (RFC6749) does not specify verifying that the access token > belongs to the client accessing protected resources, of which revocation = is > one. It is the role of the access token alone to signify authorization > required to make requests to protected resources. If this is an issue for > revocation, then it is an issue for all protected resources and counter > measures may be proposed in a separate RFC rather than broadening the sco= pe > of this particular RFC. As per the original text itself, "This > specification in general does not intend to provide countermeasures again= st > token theft and abuse." Additionally, "If an attacker is able to > successfully guess a public client's client_id and one of their tok > > ens, or a private client's credentials and one of their tokens, they > could do much worse damage by using the token elsewhere than by revoking > it. If they chose to revoke the token, the legitimate client will lose i= ts > authorization grant and will need to prompt the user again. No further > damage is done and the guessed token is now worthless." > > Note that the client_id is not meant to be private information to begin > with, so relying on an attacker "guessing" it should not be seen as a > security countermeasure. This section of RFC7009 will be referenced in a > subsequent errata. > > > > 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. > > > > -------------------------------------- > > RFC7009 (draft-ietf-oauth-revocation-11) > > -------------------------------------- > > Title : OAuth 2.0 Token Revocation > > Publication Date : August 2013 > > Author(s) : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu > > Category : PROPOSED STANDARD > > Source : Web Authorization Protocol > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --00000000000096031f05caef7500 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with you Justin.

While there pr= obably is a need for an errata to this RFC wrt public clients, it wouldn= 9;t be the one proposed here.

Wrt public clients, = section 5 states:

=C2=A0 =C2=A0According to this s= pecification, a client's request must contain a
=C2=A0 =C2=A0valid c= lient_id, in the case of a public client, or valid client
=C2=A0 =C2=A0c= redentials, in the case of a confidential client.

<= div>but actually nowhere in the specification is defined how a public clien= t would pass its client_id in the request.

As an e= rrata, this section should probably be reworded to remove any mention of pu= blic clients.
And then the RFC should possibly be obsoleted with = a new one properly supporting the public clients' use case (and then I = would argue just adding a client_id parameter alongside token and token_typ= e_hint)

As far as the currently proposed change is= concerned, there's no point in accepting as authorization the same acc= ess token that would be revoked, as this would be exactly the same, securit= y-wise, as not having authentication at all.

On Mon, Aug 23, 2021 at 9= :42 PM Justin Richer <jricher@mit.edu= > wrote:
= I personally don=E2=80=99t agree with this errata. Token Revocation was nev= er meant to act as a protected resource, but rather as a function of the AS= . The client is known to the AS and so authentication is expected here.

=C2=A0=E2=80=94 Justin

> On Aug 22, 2021, at 5:14 AM, RFC Errata System <rfc-editor@rfc-editor.org&g= t; wrote:
>
> The following errata report has been submitted for RFC7009,
> "OAuth 2.0 Token Revocation".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6663
>
> --------------------------------------
> Type: Technical
> Reported by: Ashvin Narayanan <ashvinnarayanan@gmail.com>
>
> Section: 2.1
>
> Original Text
> -------------
> The client constructs the request by including the following
>=C2=A0 =C2=A0parameters using the "application/x-www-form-urlencod= ed" format in
>=C2=A0 =C2=A0the HTTP request entity-body:
>
>=C2=A0 =C2=A0token=C2=A0 =C2=A0REQUIRED.=C2=A0 The token that the clien= t wants to get revoked.
>
>=C2=A0 =C2=A0token_type_hint=C2=A0 OPTIONAL.=C2=A0 A hint about the typ= e of the token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0submitted for revocation.=C2= =A0 Clients MAY pass this parameter in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0order to help the authorizatio= n server to optimize the token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lookup.=C2=A0 If the server is= unable to locate the token using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the given hint, it MUST extend= its search across all of its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0supported token types.=C2=A0 A= n authorization server MAY ignore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this parameter, particularly i= f it is able to detect the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token type automatically.=C2= =A0 This specification defines two
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such values:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* access_token: An access toke= n as defined in [RFC6749],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 1.4
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* refresh_token: A refresh tok= en as defined in [RFC6749],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 1.5
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Specific implementations, prof= iles, and extensions of this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specification MAY define other= values for this parameter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using the registry defined in = Section 4.1.2.
>
>=C2=A0 =C2=A0The client also includes its authentication credentials as= described
>=C2=A0 =C2=A0in Section 2.3. of [RFC6749].
>
>=C2=A0 =C2=A0For example, a client may request the revocation of a refr= esh token
>=C2=A0 =C2=A0with the following request:
>
>=C2=A0 =C2=A0 =C2=A0POST /revoke HTTP/1.1
>=C2=A0 =C2=A0 =C2=A0Host: server.example.com
>=C2=A0 =C2=A0 =C2=A0Content-Type: application/x-www-form-urlencoded
>=C2=A0 =C2=A0 =C2=A0Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW >
>=C2=A0 =C2=A0 =C2=A0token=3D45ghiukldjahdnhzdauz&token_type_hint=3D= refresh_token
>
>=C2=A0 =C2=A0The authorization server first validates the client creden= tials (in
>=C2=A0 =C2=A0case of a confidential client) and then verifies whether t= he token
>=C2=A0 =C2=A0was issued to the client making the revocation request.=C2= =A0 If this
>=C2=A0 =C2=A0validation fails, the request is refused and the client is= informed
>=C2=A0 =C2=A0of the error by the authorization server as described belo= w.
>
> Corrected Text
> --------------
> The client calls the revocation endpoint using an HTTP
>=C2=A0 =C2=A0POST [RFC7231] request with the following parameters sent = as
>=C2=A0 =C2=A0"application/x-www-form-urlencoded" data in the = request body:
>
>=C2=A0 =C2=A0token=C2=A0 =C2=A0REQUIRED.=C2=A0 The token that the clien= t wants to get revoked.
>
>=C2=A0 =C2=A0token_type_hint=C2=A0 OPTIONAL.=C2=A0 A hint about the typ= e of the token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0submitted for revocation.=C2= =A0 Clients MAY pass this parameter in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0order to help the authorizatio= n server to optimize the token
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0lookup.=C2=A0 If the server is= unable to locate the token using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the given hint, it MUST extend= its search across all of its
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0supported token types.=C2=A0 A= n authorization server MAY ignore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this parameter, particularly i= f it is able to detect the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token type automatically.=C2= =A0 This specification defines two
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0such values:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* access_token: An access toke= n as defined in [RFC6749],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 1.4
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* refresh_token: A refresh tok= en as defined in [RFC6749],
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 1.5
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Specific implementations, prof= iles, and extensions of this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0specification MAY define other= values for this parameter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using the registry defined in = Section 4.1.2.
>
>=C2=A0 =C2=A0The client MUST also include in the request, the access to= ken it received
>=C2=A0 =C2=A0from the authorization server. It must do so in the same w= ay as it=C2=A0 would=C2=A0
>=C2=A0 =C2=A0when accessing a protected resource, as describe in [RFC67= 49], Section 7.
>
>=C2=A0 =C2=A0The following is a non-normative example request in which = the client uses
>=C2=A0 =C2=A0its access token to revoke the associated refresh token: >
>=C2=A0 =C2=A0 =C2=A0POST /revoke HTTP/1.1
>=C2=A0 =C2=A0 =C2=A0Host: server.example.com
>=C2=A0 =C2=A0 =C2=A0Content-Type: application/x-www-form-urlencoded
>=C2=A0 =C2=A0 =C2=A0Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW<= br> >
>=C2=A0 =C2=A0 =C2=A0token=3D45ghiukldjahdnhzdauz&token_type_hint=3D= refresh_token
>
>=C2=A0 =C2=A0The following is a non-normative example request in which = the client uses
>=C2=A0 =C2=A0its access token to revoke the same access token:
>
>=C2=A0 =C2=A0 =C2=A0POST /revoke HTTP/1.1
>=C2=A0 =C2=A0 =C2=A0Host: server.example.com
>=C2=A0 =C2=A0 =C2=A0Content-Type: application/x-www-form-urlencoded
>=C2=A0 =C2=A0 =C2=A0Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW<= br> >
>=C2=A0 =C2=A0 =C2=A0token=3DczZCaGRSa3F0MzpnWDFmQmF0M2JW&token_type= _hint=3Daccess_token
>
>=C2=A0 =C2=A0The authorization server MUST validate the access token us= ed by the=C2=A0 =C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0client to authorize its call to the revocation endpoint, i= ncluding
>=C2=A0 =C2=A0ensuring that it is not expired or revoked.
>=C2=A0 =C2=A0Additionally, the authorization server MUST also validate = whether the
>=C2=A0 =C2=A0access token used for authorization is part of the same gr= ant=C2=A0 as the
>=C2=A0 =C2=A0token being revoked. If validation fails, the request is= =C2=A0 refused and
>=C2=A0 =C2=A0the client is informed of the error by the authorization s= erver.
>=C2=A0 =C2=A0In the case of a bearer token, the authorization server SH= OULD respond=C2=A0
>=C2=A0 =C2=A0with an HTTP 401 code as described in OAuth 2.0 Bearer Tok= en Usage
>=C2=A0 =C2=A0[RFC6750], Section 3.
>=C2=A0 =C2=A0Errors based on other types of tokens are beyond the scope= of this
>=C2=A0 =C2=A0specification.
>
>
> Notes
> -----
> It appears as though the authors of RFC7009 have failed to consider th= at requests to revoke are likely to come from non-confidential clients and = such, would lack authentication credentials. Regardless of the type of clie= nt however, authentication should not be required. The OAuth 2.0 specificat= ion (RFC6749) does not specify verifying that the access token belongs to t= he client accessing protected resources, of which revocation is one. It is = the role of the access token alone to signify authorization required to mak= e requests to protected resources. If this is an issue for revocation, then= it is an issue for all protected resources and counter measures may be pro= posed in a separate RFC rather than broadening the scope of this particular= RFC. As per the original text itself, "This specification in general = does not intend to provide countermeasures against token theft and abuse.&q= uot; Additionally, "If an attacker is able to successfully guess a pub= lic client's client_id and one of their tok
> ens, or a private client's credentials and one of their tokens, th= ey could do much worse damage by using the token elsewhere than by revoking= it.=C2=A0 If they chose to revoke the token, the legitimate client will lo= se its authorization grant and will need to prompt the user again.=C2=A0 No= further damage is done and the guessed token is now worthless."
> Note that the client_id is not meant to be private information to begi= n with, so relying on an attacker "guessing" it should not be see= n as a security countermeasure. This section of RFC7009 will be referenced = in a subsequent errata.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC7009 (draft-ietf-oauth-revocation-11)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: OAuth 2.= 0 Token Revocation
> Publication Date=C2=A0 =C2=A0 : August 2013
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Lodderstedt, Ed= ., S. Dronia, M. Scurtescu
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Web Authoriza= tion Protocol
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

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


--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--00000000000096031f05caef7500-- From nobody Wed Sep 1 16:09:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399B03A1D26 for ; Wed, 1 Sep 2021 16:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iy2296wLyTos for ; Wed, 1 Sep 2021 16:09:10 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0: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 C45663A1D2B for ; Wed, 1 Sep 2021 16:09:10 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id u25so239016oiv.5 for ; Wed, 01 Sep 2021 16:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=h9ymqRoki4LlAF2z/b30i0UqPn0i52V0p+kAxfCsXNs=; b=EVld8/8OkjDOFrqJK7bYIwadXYQmETbWggFKZctQk9mnOt0/Rb+hqByqiecgXgMfAr mWMZKcQ/89MSFgWaWgQD6VAPtnoMPAkdlyoBuJoJ9AcNLC1V+LqjtsnTatOV8xNQcLZN zS2/8luHgh6298zB5b3GawQN/Lz8Q0n8vKVrsC0XiynUSqXWrQWN+klP9QPk/C4JFs0H cwwAeJ9cOVMryQb1O1M/M30S6Os+pB7ZGRV13UQpP6ZtatogTJpfTRXD/QPZWjKzEVdU aVCVZtIChJnlyBQjoDajTOMqgCnUkQlooU7z3i5Ajqxgh3aoOLZ910EtzqRebl4OeWHH DFbg== 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=h9ymqRoki4LlAF2z/b30i0UqPn0i52V0p+kAxfCsXNs=; b=aYxHDgRy1KC7DQAz7nsRsupHjHNCO9nBHvI6OCsCqiomjqgnsDeWT6vIIp8jK5c1Y6 +1QX18S6FnSbNfRS3NHc2FnSfQ6y5AmhqkNXTMSpbeHqDnV5okyfYEaZtLflXOSssDqb wrOCWcCJLn4aGKhV4cPtIFUykI7bmDoCLcS/182Q9iXmB4ey3dggh9LmE9YQcGxNyWVQ mZhrOHquQG1KystNPRYfLG628r6RUqj6PHK2vLYASWKmAVsuTNs3p4lqXJwYi63O1QU1 g9A4ofcHVaQDRtFhOavUQfrLxlM9xiMtCNRGR750dcCoMgDqG6bAe9PjJhavoNKzB3nv Gulg== X-Gm-Message-State: AOAM5322LnFWkyoiRVIGbsRvS2X+BscAutDYefdDC9lpyFqZaDVunZcv 2xc9kpUUMyyqicEht+ylRBAkHOVqUNsFWJDNFgA= X-Google-Smtp-Source: ABdhPJyilRRALRhXxKLDFvSLr8+9ncAcfDgq0naPjS+aN7qZSVQIvwJoZbVlITd/TGyc5SxNu32GYWSJ4L6x4rqbC/8= X-Received: by 2002:aca:3193:: with SMTP id x141mr131438oix.110.1630537749000; Wed, 01 Sep 2021 16:09:09 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Ash Narayanan Date: Thu, 2 Sep 2021 09:08:57 +1000 Message-ID: To: Thomas Broyer Cc: IETF oauth WG , mscurtescu@google.com, sdronia@gmx.de Content-Type: multipart/alternative; boundary="00000000000052773405caf727d6" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-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, 01 Sep 2021 23:09:33 -0000 --00000000000052773405caf727d6 Content-Type: text/plain; charset="UTF-8" Hi Thomas, The approach you've suggested sounds good. Passing just the client_id along with the token and type (regardless of client type) would be consistent with how refresh_token requests are structured. As long as the new RFC obsoletes this one. Ash --00000000000052773405caf727d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,

The approach you've sugg= ested sounds good. Passing just the client_id along with the token and type= (regardless of client type) would be consistent with how refresh_token req= uests are structured. As long as the new RFC obsoletes this one.
=
Ash
--00000000000052773405caf727d6-- From nobody Wed Sep 1 23:42:06 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB7D3A0C0A for ; Wed, 1 Sep 2021 23:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3IoLmWfUc1Z for ; Wed, 1 Sep 2021 23:41:59 -0700 (PDT) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6E93A0C06 for ; Wed, 1 Sep 2021 23:41:59 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id c6so1801099ybm.10 for ; Wed, 01 Sep 2021 23:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j6eSpQBj4cMUb2mCctxlzO1gNkwP1OTXSJOzlshhEVs=; b=WwBRJX4X7aFR7XaixRebr7w8NVYXULyoJPvkLAM+W3oY0yGLm0rzKrscsFMZP9G2fy KLxfp4uSm1v44GwLfeNno0ftajbkkUqac6WOLkhdHUvCnF1o0sHEGn78aIypcj10FGzk cRJYCQ+ERnL9vQL6fyg+Olw9L5OZ13vSRn+wTlNJKxWydeGVlY+nROH5BvIGQOhbeBon m+cCJnj4nc0Psq56IO1OD7/h1YWUWPzYAF5bW3m+f3VzTZVgpZb1bK5df0LApJLNzLNa nc+g4higbAmC0eqaiT5mbJlFNMbqWgnepll5ADLh5MYUexn46yi1WGo1lmoWVVm9zj9J Y+8g== 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=j6eSpQBj4cMUb2mCctxlzO1gNkwP1OTXSJOzlshhEVs=; b=WBaLoJ4QpmN2za+9IJ/tsggsAt8FGLB2A9E4ub1ZKvoy6XvWOowcCdyaZeBvilD8MO aA4iit5CAt9xGVffUDE4HHlFeILG6+7WG+vGR9UbRU33ghJuseT6HAuYU3vjv9r2/6ES CvtdQ9wTzMOrf68Fzwg757a0TOHThRZuk5LL+PZUGAYIMfgXNnWbZmcu2JAsY//D0X0J EmnZ4fLhEDEcCamRODN3x6kaDcZ+yzbLRXwLgeybU5FpHpwdI+dipskhQzTVoXt4FxhX vbAxECFPaaY8xdQcsSe3tMlcDPk4xUgedoAz+KYCn8vvwTCmzDnHa+77IGuNNZjA2KZ1 iZWw== X-Gm-Message-State: AOAM533dSfWTwveJmZ5PMnAgtcUo8o9FsULsi36P97uQWBtQ6NVh2k2G 5xgXIpDxhN1WZem2msEx6p+lU7H6NPumPljs6dcm X-Google-Smtp-Source: ABdhPJxznBBJ+zFvDYxfWisvQptX2LBMEq4qXWZnowGwcOZ+1hbuiA0ZYidbvypa1eWBhjPr3QxoX3gwWSC/e2MIrqQ= X-Received: by 2002:a25:b948:: with SMTP id s8mr2410401ybm.281.1630564916905; Wed, 01 Sep 2021 23:41:56 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Warren Parad Date: Thu, 2 Sep 2021 08:41:46 +0200 Message-ID: To: Ash Narayanan Cc: Thomas Broyer , sdronia@gmx.de, IETF oauth WG , mscurtescu@google.com Content-Type: multipart/alternative; boundary="000000000000a7dd4305cafd7a7e" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 06:42:05 -0000 --000000000000a7dd4305cafd7a7e Content-Type: text/plain; charset="UTF-8" What's the point in passing arbitrary other information that is already known by the AS and does not provide the level of security necessary to prevent abuse of the revocation endpoint? On Thu, Sep 2, 2021, 01:12 Ash Narayanan wrote: > Hi Thomas, > > The approach you've suggested sounds good. Passing just the client_id > along with the token and type (regardless of client type) would be > consistent with how refresh_token requests are structured. As long as the > new RFC obsoletes this one. > > Ash > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000a7dd4305cafd7a7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What's the point in passing arbitrary other informati= on that is already known by the AS and does not provide the level of securi= ty necessary to prevent abuse of the revocation endpoint?

On Thu, Sep 2, 202= 1, 01:12 Ash Narayanan <ash= vinnarayanan@gmail.com> wrote:
Hi Thomas,

The approach you've s= uggested sounds good. Passing just the client_id along with the token and t= ype (regardless of client type) would be consistent with how refresh_token = requests are structured. As long as the new RFC obsoletes this one.

Ash
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a7dd4305cafd7a7e-- From nobody Wed Sep 1 23:52:49 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4BF3A0CAB for ; Wed, 1 Sep 2021 23:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 NCjpd3PlpaBM for ; Wed, 1 Sep 2021 23:52:36 -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 462B93A0C7C for ; Wed, 1 Sep 2021 23:52:36 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id q39so1314236oiw.12 for ; Wed, 01 Sep 2021 23:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Keo5Z9HU9JmcfOuh//lx63Vu0IxZSUothYJJw0JkNgA=; b=VHCr0xHRVKkcCk/qdirWw95kGxTdJ9aNsXpSDEHGboTxAwPBzpcrwddvqC8bsJDHj2 bRokjUP13TlzKoxvzVbJpPmNnTKp+fq3u1jHQNVc6BnwfXWu6RzkwAk5cYuoM4p4jo2x oy9UbjnEhFN+xKxLVZVwqf1Iwr1iZR3Hz54kBN898CFhhJrBdnwdZT9j60ztq//FSFSg 3GfC4OLOnH1ujRZcdjGbJ9EGFz5Yoby3eHxypm4hfoFkWX1ZZTkSecJLh/QvKActb97o WMMhCLM0I+VZMZXNdsolSX6/fHJwsY6b8JxwEFhZgyAQnJI6egUoJt2MeL7FW16ipfcn FitA== 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=Keo5Z9HU9JmcfOuh//lx63Vu0IxZSUothYJJw0JkNgA=; b=HgZQEgkdgSnUm2ECVn8bAgRe+DA3mRy2oT4Ie35e2Dm4q3FcqXSIb+t3m2m5BkymJL iodtfDVQ+7CgjyMfgkQmbG0KKoI1uPxOnMjs9PhsTiHvQtQmu8xs76OPIpXsPoFTmzEd Vev9O62NyHY8zCk+WJq/PTUUINFhB9Y0zUSrf6jW4oo1+VYPS8CpjYmcpJKQS+LLErJ0 aEgx15hPgQqWjEhmypL5F/siFtB0qHmDhdX0tHZAqzxM2OyZe9h6mhkMGgmBrqU9OZQt 0qDRrBHik9meuZjTZ8tmuUqIq9R0EaW5tF2HOADkF/rWgHWaUwDFOdrsbVR6kEfCT632 19VA== X-Gm-Message-State: AOAM53020VNXdFv2I9RThrflEE8jFKcECY/YeYaMyAyFxK6hFzguxGKz b6T5DpGLGQkNPQcek7xLVkSOgHBC4kVpCi+BMY7BGvmcM7I= X-Google-Smtp-Source: ABdhPJwLCy0CUaVwH0kgkUlC312y7gSeTP8Vnx0oX2fPL9/yxzn2dOw2n7qvgtMPOQ8lZIaJroqTRl+A5ZRZ6oz07OE= X-Received: by 2002:a05:6808:657:: with SMTP id z23mr1195523oih.113.1630565553987; Wed, 01 Sep 2021 23:52:33 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Ash Narayanan Date: Thu, 2 Sep 2021 16:52:22 +1000 Message-ID: To: Warren Parad Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a0e35a05cafda0b8" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 06:52:48 -0000 --000000000000a0e35a05cafda0b8 Content-Type: text/plain; charset="UTF-8" Hi Warren, If you are referring to the client_id as arbitrary information, then the same would also be true for refresh requests to the token endpoint from public clients. As per 6749, you need to pass the client_id along with the refresh token. The client_id adds no additional security. But really, the whole point I've been trying to make from the start is that the token itself should be the only form of 'security' needed...as that's the point of OAuth. Regardless, 7009 needs to be made obsolete by a newer RFC. Ash On Thu, Sep 2, 2021 at 4:41 PM Warren Parad wrote: > What's the point in passing arbitrary other information that is already > known by the AS and does not provide the level of security necessary to > prevent abuse of the revocation endpoint? > > On Thu, Sep 2, 2021, 01:12 Ash Narayanan > wrote: > >> Hi Thomas, >> >> The approach you've suggested sounds good. Passing just the client_id >> along with the token and type (regardless of client type) would be >> consistent with how refresh_token requests are structured. As long as the >> new RFC obsoletes this one. >> >> Ash >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000a0e35a05cafda0b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Warren,

If you are referring to the = client_id as arbitrary information, then the same would also be true for re= fresh requests to the token endpoint from public clients.=C2=A0 As per 6749= , you need to pass the client_id along with the refresh token. The client_i= d adds no additional security.

But really, the who= le point I've been trying to make from the start is that the token itse= lf should be the only form of 'security' needed...as that's the= point of OAuth.

Regardless, 7009 needs to be made= obsolete by a newer RFC.

Ash

On Thu, Sep 2, = 2021 at 4:41 PM Warren Parad <wparad= @rhosys.ch> wrote:
What= 's the point in passing arbitrary other information that is already kno= wn by the AS and does not provide the level of security necessary to preven= t abuse of the revocation endpoint?

On Thu, Sep 2, 2021, 01:12 Ash Narayanan= <ashvinn= arayanan@gmail.com> wrote:
Hi Thomas,

The approach you've suggested sounds go= od. Passing just the client_id along with the token and type (regardless of= client type) would be consistent with how refresh_token requests are struc= tured. As long as the new RFC obsoletes this one.

= Ash
_______________________________________________
OAuth mailing list
OAut= h@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a0e35a05cafda0b8-- From nobody Thu Sep 2 00:16:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4213A104B for ; Thu, 2 Sep 2021 00:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_ZA_HViDWWC for ; Thu, 2 Sep 2021 00:16:39 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3E03A1045 for ; Thu, 2 Sep 2021 00:16:39 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id r4so1998013ybp.4 for ; Thu, 02 Sep 2021 00:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=93qmikd8W4ovZvnBw/SinvJZghsO83f8Q/Jnmk/0ZkU=; b=dF0+K2+bqyBHUjwfwXC5EZLyVNSFRzeHP74IqM5qo2ltn9+eb7W6MPa+04A9E5xleF 6ANnNRuQzYzu0A9+cXh5zRtL3WWnOaycL232Pd/8BQCKdU0x78MP24+GFA+yw7Nxr06/ 8tsZhZ5JxXHTrRypXbHAvmOrY3kNKC3fpv5uRWlVvSweyj8bmUiM/C1ExY7AJj4Fa4Q1 FN4nbKi6fPYDR7xv5KWIkNgdy+roMXX8WkzFxT4e+wqF0jvd3ZyT649ua4GMM9F8hwV9 5mULRNLfuirp7KQQg3aedZKENDxXNsSjuu+9B0yIB5AxClofxPclRM7lgZXlZRDLiyRB x2IA== 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=93qmikd8W4ovZvnBw/SinvJZghsO83f8Q/Jnmk/0ZkU=; b=PyE+LcFVvlAb6IbVPagk4kbOBpvgiiImuq8QmTmK+uWw7nEYJFfYWrkxE6CiFdzzqh vLrLowjMt5iVaJwtet1rkUXiqIS4XZ4Cunq3+HPML+K/wChd3W4lBqDLcWa3eqwOiZPR Sj8VvfEEzAPt2AnZErRbicX+RVLffZ8AdliRMx1D0g8tfPfSnQyZfDLCQ2v1OP/mHS0+ PFBbKX7/3p0IFDN5hKJOUl+pNJwm0LF9ZLC7bVK9eIwsRRqBcJerXWiVox5hFfYUsLPU UqbbURJWfeAeRoJLUTgLtHGUwd3VVMCydpMNwbKsUCWl8NrrIh01a3Jq9ppE0kxW72Vh k6FA== X-Gm-Message-State: AOAM533qFoRl5j8tlVl77pqrm6BqUBmkFlKQ/R24a4n90PlveNtXIwwU W9zbATt5OOx+xEEATQH6dMjzYvs0YG64koIMOy6G X-Google-Smtp-Source: ABdhPJwyg8B1xVg9tlT6Sp1oWgz8PzdotmvNu/xsq0bXS6p+ZOtcRbMVbjtZgm5JVWw9uWtvQlVoAfNmsc4dpyr7oIs= X-Received: by 2002:a25:440b:: with SMTP id r11mr2483409yba.44.1630566997213; Thu, 02 Sep 2021 00:16:37 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Warren Parad Date: Thu, 2 Sep 2021 09:16:26 +0200 Message-ID: To: Ash Narayanan Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a6d77d05cafdf6b6" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 07:16:46 -0000 --000000000000a6d77d05cafdf6b6 Content-Type: text/plain; charset="UTF-8" Great, then let's fix 6749 not this one. The client_id isn't necessary. And then wouldn't 7009 not need to be changed because it already says you don't need to pass any authorization for public clients? For credentialled client issued grants, refresh tokens, and access tokens, these must not be able to be revoked without client credentials, so using the refresh token or access token only for all other client types must not be supported. On Thu, Sep 2, 2021, 08:52 Ash Narayanan wrote: > Hi Warren, > > If you are referring to the client_id as arbitrary information, then the > same would also be true for refresh requests to the token endpoint from > public clients. As per 6749, you need to pass the client_id along with the > refresh token. The client_id adds no additional security. > > But really, the whole point I've been trying to make from the start is > that the token itself should be the only form of 'security' needed...as > that's the point of OAuth. > > Regardless, 7009 needs to be made obsolete by a newer RFC. > > Ash > > On Thu, Sep 2, 2021 at 4:41 PM Warren Parad wrote: > >> What's the point in passing arbitrary other information that is already >> known by the AS and does not provide the level of security necessary to >> prevent abuse of the revocation endpoint? >> >> On Thu, Sep 2, 2021, 01:12 Ash Narayanan >> wrote: >> >>> Hi Thomas, >>> >>> The approach you've suggested sounds good. Passing just the client_id >>> along with the token and type (regardless of client type) would be >>> consistent with how refresh_token requests are structured. As long as the >>> new RFC obsoletes this one. >>> >>> Ash >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> --000000000000a6d77d05cafdf6b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, then let's fix 6749 not this = one. The client_id isn't necessary.

And then wouldn't 7009 not need to be changed because i= t already says you don't need to pass any authorization for public clie= nts?

For credentialled c= lient issued grants, refresh tokens, and access tokens, these must not be a= ble to be revoked without client credentials, so using the refresh token or= access token only for all other client types must not be supported.

On Thu, Sep 2, 2021, 08:52 Ash Narayanan <ashvinnarayanan@gma= il.com> wrote:
Hi Warren,

If you are referring to the client_id as = arbitrary information, then the same would also be true for refresh request= s to the token endpoint from public clients.=C2=A0 As per 6749, you need to= pass the client_id along with the refresh token. The client_id adds no add= itional security.

But really, the whole point I= 9;ve been trying to make from the start is that the token itself should be = the only form of 'security' needed...as that's the point of OAu= th.

Regardless, 7009 needs to be made obsolete by = a newer RFC.

Ash

On Thu, Sep 2, 2021 at 4:41 = PM Warren Parad <wparad@rhosys.ch> wrote:
What's the point in passing arbitrary other informat= ion that is already known by the AS and does not provide the level of secur= ity necessary to prevent abuse of the revocation endpoint?

On Thu, Sep 2, 20= 21, 01:12 Ash Narayanan <ashvinnarayanan@gmail.com> wrote:=
Hi Thomas,

T= he approach you've suggested sounds good. Passing just the client_id al= ong with the token and type (regardless of client type) would be consistent= with how refresh_token requests are structured. As long as the new RFC obs= oletes this one.

Ash
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
--000000000000a6d77d05cafdf6b6-- From nobody Thu Sep 2 01:21:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650183A00D6 for ; Thu, 2 Sep 2021 01:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 2GHPMXXX1sM0 for ; Thu, 2 Sep 2021 01:21:46 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017513A00C8 for ; Thu, 2 Sep 2021 01:21:45 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id q39so1543098oiw.12 for ; Thu, 02 Sep 2021 01:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZvuniaDTAng1TsT1udbxPUm4UMzGM314GQEU9TycAZE=; b=MK3KNWDVwBLrO0sB0ZyVHU62Lp+hMfV4IrAwxHuX8iu+Y5CUsVgacLQmjG5wLaWcey 6H67dqU++zULOCBYq/0wLzB5QAxqwO/FAjpHqR4/EQJ2LXEahIuNCJGt5p/p/zsgZWyE a8fYni2OZeCo4RLyzpyHE850NzkWq+3Tm2/fDwe2aKiqsQpWW3Jj/QYeO548kdWJuEE8 ednuBhuCX0AQb797eOo8HhZQc+fbIFiVlm+5A2ZI8GTR6PJeRYkYxhke7dGQtBs57GZQ Hv+v2ooHh4WTCpv2+kfoQF71RLI0n0YBKfVJMO7PhGkK1k6hpN61TfFv4WLjkT/z2udR SAUg== 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=ZvuniaDTAng1TsT1udbxPUm4UMzGM314GQEU9TycAZE=; b=Z5c2PNpst7JF9mgNcNa6Ey+191eDkRJ7/tFsWJ3xZHmhOxJDpTo4AwUZZJOcat0lO8 0xyQNDBCxL2G9vUGbVl0Ja12ra/62/gDKXHQeoPLZpHkOW2jrYZ5GHeOqOEHkjkKvYnd AP8cv5Q2DvcV5LDTf3823AM6Yf2bH+4nO9ls+hBXF581yz+UAKWkFVohDfkhcVgp+pSS +1aFwgFHGTPDnTGuz542U4mf1H7yYeAbu4suXYqDU3ShACIPHC/POksIsSVx1Dia78fx oBxJFZ6bxS+udX0XDPY9N9ca1y8ZGmrNSKa0phv9S9Nbjwj9mZkLr1rmxWNHRBWcuOvE gU7Q== X-Gm-Message-State: AOAM531usKT5aBH53hR2BOv0XnQ07PGbNBYPmkubz7bL/JpD0WF3wODf JMPzv8tIqCe/asYOIOtBAsOXOGAxc+R9J10kRFAtoHLe5QPHkg== X-Google-Smtp-Source: ABdhPJwLsZ2IgYJmos7GmZtYG067pOAku18u53jMjPi6OjXLLVFE+a5UHFWBb6bbnc8dawMHAyLHlmfb7c2+CkbD2cw= X-Received: by 2002:aca:3193:: with SMTP id x141mr1320355oix.110.1630570902320; Thu, 02 Sep 2021 01:21:42 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Ash Narayanan Date: Thu, 2 Sep 2021 18:21:31 +1000 Message-ID: To: Warren Parad Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000069fab705cafedf31" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 08:21:52 -0000 --00000000000069fab705cafedf31 Content-Type: text/plain; charset="UTF-8" Hey Warren, 7009 states that you need to pass just the client_id for public clients, so if: > The client_id isn't necessary. > Then obviously something about 7009 needs to change. Whichever angle you look at, 7009 needs to change. On Thu, Sep 2, 2021 at 5:16 PM Warren Parad wrote: > Great, then let's fix 6749 not this one. The client_id isn't necessary. > > And then wouldn't 7009 not need to be changed because it already says you > don't need to pass any authorization for public clients? > > For credentialled client issued grants, refresh tokens, and access tokens, > these must not be able to be revoked without client credentials, so using > the refresh token or access token only for all other client types must not > be supported. > > On Thu, Sep 2, 2021, 08:52 Ash Narayanan > wrote: > >> Hi Warren, >> >> If you are referring to the client_id as arbitrary information, then the >> same would also be true for refresh requests to the token endpoint from >> public clients. As per 6749, you need to pass the client_id along with the >> refresh token. The client_id adds no additional security. >> >> But really, the whole point I've been trying to make from the start is >> that the token itself should be the only form of 'security' needed...as >> that's the point of OAuth. >> >> Regardless, 7009 needs to be made obsolete by a newer RFC. >> >> Ash >> >> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad wrote: >> >>> What's the point in passing arbitrary other information that is already >>> known by the AS and does not provide the level of security necessary to >>> prevent abuse of the revocation endpoint? >>> >>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan >>> wrote: >>> >>>> Hi Thomas, >>>> >>>> The approach you've suggested sounds good. Passing just the client_id >>>> along with the token and type (regardless of client type) would be >>>> consistent with how refresh_token requests are structured. As long as the >>>> new RFC obsoletes this one. >>>> >>>> Ash >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> --00000000000069fab705cafedf31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Warren,

7009 states that you need t= o pass just the client_id for public clients, so if:
= The client_id isn't necessary.

Then= obviously something about 7009 needs to change.

W= hichever angle you look at, 7009 needs to change.=C2=A0

On Thu, Sep 2,= 2021 at 5:16 PM Warren Parad <wpara= d@rhosys.ch> wrote:
Great, then let's fix 6749 not this one. The client_id isn= 't necessary.

And th= en wouldn't 7009 not need to be changed because it already says you don= 't need to pass any authorization for public clients?

For credentialled client issued grants, r= efresh tokens, and access tokens, these must not be able to be revoked with= out client credentials, so using the refresh token or access token only for= all other client types must not be supported.

= On Thu, Sep 2, 2021, 08:52 Ash Narayanan <ashvinnarayanan@gmail.com> wrote:
Hi Warren,

If = you are referring to the client_id as arbitrary information, then the same = would also be true for refresh requests to the token endpoint from public c= lients.=C2=A0 As per 6749, you need to pass the client_id along with the re= fresh token. The client_id adds no additional security.

But really, the whole point I've been trying to make from the sta= rt is that the token itself should be the only form of 'security' n= eeded...as that's the point of OAuth.

Regardle= ss, 7009 needs to be made obsolete by a newer RFC.

Ash

On Thu, Sep 2, 2021 at 4:41 PM Warren Parad <wparad@rhosys.ch> wrote:

On Thu, Sep 2, 2021, 01:12 Ash Narayanan <= ashvinnarayanan@gmail.com> wrote:
Hi Thomas,

The approach you've suggested so= unds good. Passing just the client_id along with the token and type (regard= less of client type) would be consistent with how refresh_token requests ar= e structured. As long as the new RFC obsoletes this one.

Ash
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
--00000000000069fab705cafedf31-- From nobody Thu Sep 2 01:22:46 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBE23A0317 for ; Thu, 2 Sep 2021 01:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tk_6C9HJX-hR for ; Thu, 2 Sep 2021 01:22:38 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB93F3A03F1 for ; Thu, 2 Sep 2021 01:22:38 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id f15so2300399ybg.3 for ; Thu, 02 Sep 2021 01:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kEC4NJ4wtKzeuUQ1iFe5Pj4uM2XS7XXT+2WgHUQ1ur4=; b=gDvaxHoMV4YVkTVxQoBIc3vPrkcXnugFIcG4gfiuye3GLCVO8BYPYDBDcCPhESywG1 uNA2N9RZk1xmc8Tjrj+iM9rMR1kekEWQkMNO5yD46M6UNlQE/F8nYlhlE9oX+qtU9Gmq 2q+YYTPaOo186eBkq3U7jiZ2uIYwpU8Ln6EVPoFT5TxNwIM7vC67Aetv3sz3qWaJ/X9g wP6DBVJ+m9YTmfxvKVKT3TGipiM8deRozsiXjrAisGKheBY3x5ukEbw4+ZxXsuLsujSn QN4/zwsXNQMAI0lAG5a+Xx30XaL8OrOI896JVGkB0GJEDjj5JP5Gs/FK0gJuITqckga1 spMQ== 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=kEC4NJ4wtKzeuUQ1iFe5Pj4uM2XS7XXT+2WgHUQ1ur4=; b=MU/+0PyVnEl+MT+N2+0P4lqWUsXdZnOfZxrZo8Svx0rHZ93AVCtYxU0aIBlrL/YXVu MLm28RXvg4dyDBsD64Nx1SQLj1sY7taUl+4HL0zGEuztAOidtM5mi8rCqXtl1+FN3rQh XYt0rQLSofoaLqAPqCBavPcJT854tjznZUBNl4rf2vg9pQc+bf1bpQ20V3uovRYDJ5od HvWPhZvlV3bUBXlrkgYfeuPIa91jpElw41SCI6toWW2kwUQgMBpgNxbL2nEIjQ78xPk7 ZVWMRorYAmE9LyMQwR55AO0hqREIn1Jb5+TjkT2izvti7XgO3WNJwMOEd1umrQW9FsWM V05Q== X-Gm-Message-State: AOAM533lN+gDMZ4CRPuaLF9P0YGpGcRjpPCDMkA28jBFrMWV6f6TvuZL RV/N8pclGiVoNwNKC/8sJHpJ/+jeqWTDAOfKaLW8mP2A/A== X-Google-Smtp-Source: ABdhPJw9eWuaDenlN9n3V1w3/5SiYIp5QixrRcT0AAxjdDhHHWdalG929t3TAECJYk9r0RiWSmbYkSE/sMPPS36KCcE= X-Received: by 2002:a25:440b:: with SMTP id r11mr2776850yba.44.1630570956473; Thu, 02 Sep 2021 01:22:36 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Warren Parad Date: Thu, 2 Sep 2021 10:22:25 +0200 Message-ID: To: Ash Narayanan Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000a4570005cafee2eb" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 08:22:45 -0000 --000000000000a4570005cafee2eb Content-Type: text/plain; charset="UTF-8" Can you point out where it says that, I think I must of missed it. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan wrote: > Hey Warren, > > 7009 states that you need to pass just the client_id for public clients, > so if: > >> The client_id isn't necessary. >> > > Then obviously something about 7009 needs to change. > > Whichever angle you look at, 7009 needs to change. > > On Thu, Sep 2, 2021 at 5:16 PM Warren Parad wrote: > >> Great, then let's fix 6749 not this one. The client_id isn't necessary. >> >> And then wouldn't 7009 not need to be changed because it already says you >> don't need to pass any authorization for public clients? >> >> For credentialled client issued grants, refresh tokens, and access >> tokens, these must not be able to be revoked without client credentials, so >> using the refresh token or access token only for all other client types >> must not be supported. >> >> On Thu, Sep 2, 2021, 08:52 Ash Narayanan >> wrote: >> >>> Hi Warren, >>> >>> If you are referring to the client_id as arbitrary information, then the >>> same would also be true for refresh requests to the token endpoint from >>> public clients. As per 6749, you need to pass the client_id along with the >>> refresh token. The client_id adds no additional security. >>> >>> But really, the whole point I've been trying to make from the start is >>> that the token itself should be the only form of 'security' needed...as >>> that's the point of OAuth. >>> >>> Regardless, 7009 needs to be made obsolete by a newer RFC. >>> >>> Ash >>> >>> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad wrote: >>> >>>> What's the point in passing arbitrary other information that is already >>>> known by the AS and does not provide the level of security necessary to >>>> prevent abuse of the revocation endpoint? >>>> >>>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan >>>> wrote: >>>> >>>>> Hi Thomas, >>>>> >>>>> The approach you've suggested sounds good. Passing just the client_id >>>>> along with the token and type (regardless of client type) would be >>>>> consistent with how refresh_token requests are structured. As long as the >>>>> new RFC obsoletes this one. >>>>> >>>>> Ash >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> --000000000000a4570005cafee2eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you point out where it says that, I think I must of mi= ssed it.

Warren Parad

Founder, CTO

Secure your user data with IAM authorization as a= service. Implement=C2=A0Authress.


On Thu, Sep 2, 2021 at 10:21= AM Ash Narayanan <ashvinna= rayanan@gmail.com> wrote:
Hey Warren,

7009 state= s that you need to pass just the client_id for public clients, so if:
=
The client_id isn't n= ecessary.

Then obviously something abou= t 7009 needs to change.

Whichever angle you look a= t, 7009 needs to change.=C2=A0

On Thu, Sep 2, 2021 at 5:16 PM Warren P= arad <wparad@rhosy= s.ch> wrote:
Great, then let's fix 6749 not t= his one. The client_id isn't necessary.

And then wouldn't 7009 not need to be changed becau= se it already says you don't need to pass any authorization for public = clients?

For credentiall= ed client issued grants, refresh tokens, and access tokens, these must not = be able to be revoked without client credentials, so using the refresh toke= n or access token only for all other client types must not be supported.

On Thu, Sep 2, 2021, 08:52 Ash Narayanan <ashvinnarayanan@= gmail.com> wrote:
Hi Warren,

If you are referr= ing to the client_id as arbitrary information, then the same would also be = true for refresh requests to the token endpoint from public clients.=C2=A0 = As per 6749, you need to pass the client_id along with the refresh token. T= he client_id adds no additional security.

But real= ly, the whole point I've been trying to make from the start is that the= token itself should be the only form of 'security' needed...as tha= t's the point of OAuth.

Regardless, 7009 needs= to be made obsolete by a newer RFC.

Ash

On T= hu, Sep 2, 2021 at 4:41 PM Warren Parad <wparad@rhosys.ch> wrote:
What's the point in passing arbitrary other information that is alread= y known by the AS and does not provide the level of security necessary to p= revent abuse of the revocation endpoint?

On Thu, Sep 2, 2021, 01:12 Ash Nara= yanan <ashvinnarayanan@gmail.com> wrote:
Hi Thomas,
<= br>
The approach you've suggested sounds good. Passing just t= he client_id along with the token and type (regardless of client type) woul= d be consistent with how refresh_token requests are structured. As long as = the new RFC obsoletes this one.

Ash
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
--000000000000a4570005cafee2eb-- From nobody Thu Sep 2 01:25:22 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31653A0147 for ; Thu, 2 Sep 2021 01:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 jpAst7pofYHB for ; Thu, 2 Sep 2021 01:25:14 -0700 (PDT) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4D53A011F for ; Thu, 2 Sep 2021 01:25:14 -0700 (PDT) Received: by mail-oo1-xc33.google.com with SMTP id j11-20020a4a92cb000000b002902ae8cb10so298286ooh.7 for ; Thu, 02 Sep 2021 01:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HTjBxHfrcTcznPItXH9aOpQ5vAS605xcsWnE5J7fpOA=; b=SkG3vl3fOsEjaSymnoJQdrMEb8LFa/m2S3XYEdQdR3zWlW2TId5BRewExZQgmFH0WX QqPY9TQFwFcQPhtv2fbqgXGwE7Nm87IqSowkghdIjbR1Am1Eoy220tOOTMTx7prpJkR4 FPsSLeZzIL3eP/50qeKbYamRI/LmPEerigYI24R2+gARdyIocTo5peT495BocqDASMNX /dBxVcum1NuyGqxCLK8a8KkJhzVic7URjAgRlNt38pRqZY9skFMoqlgqt+A1ONOmke2y +ZMfHrEQae0xQR9F6VegoN4JefQVN1e6HeH07sfmwBHKdupHb6aYfA7iygcf6ku4xEQh mRDg== 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=HTjBxHfrcTcznPItXH9aOpQ5vAS605xcsWnE5J7fpOA=; b=URvMsPX6b9GR95SDKjSEBQ4zL1bDtbGvwrRz5doPBrb5l894XydU4OkCNof+x887Sl mXexHB3LXWYcD+RkjZJHhzLxsNnFltxkEGEObem2zm7jb+l38IJvg8OLrfiP5Cgqgcex hNbWpUur+n4OHvnacXDGJNdh/4DAM8xyX1stp4sxW9qU4m1aLXRFe1U3SGBW+AdJ0H60 R6qADpew5Q8n0J5wa5Qb33qEsAsO6q3wdBwZ5r4w92SvuZ0uLoPRB5g6EyeOFBwHD8dI Rz8qULUyYP/Cw4KVSbRcrlJE/HSuNowCEw1XUFsz9QjPW7J7fM8C3VQuu4xn3liAZ2EA 893g== X-Gm-Message-State: AOAM530BBpul6Aq7RrmC81OHYcOtLSeWxgpTIJlMUdR1hMxJH5g08NYh p+pUQfH+D0/HeIdBwGWnIVBHD8ehi1x3SfdJ4MMh3snN2xXRvw== X-Google-Smtp-Source: ABdhPJwEDqJMxkjQCVKcSIspy4kZANej4qPvInCsrx53oeuOosbheXu2nVTR2WZEgSTK7eeUIMZWWdhAlOBhIzk5kCg= X-Received: by 2002:a4a:d108:: with SMTP id k8mr1626880oor.90.1630571112560; Thu, 02 Sep 2021 01:25:12 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Ash Narayanan Date: Thu, 2 Sep 2021 18:25:01 +1000 Message-ID: To: Warren Parad Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000f1fbcb05cafeebc2" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 08:25:20 -0000 --000000000000f1fbcb05cafeebc2 Content-Type: text/plain; charset="UTF-8" > > According to this specification, a client's request must contain a > valid client_id, in the case of a public client, or valid client > credentials, in the case of a confidential client. > > On Thu, Sep 2, 2021 at 6:22 PM Warren Parad wrote: > Can you point out where it says that, I think I must of missed it. > > Warren Parad > > Founder, CTO > Secure your user data with IAM authorization as a service. Implement > Authress . > > > On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan > wrote: > >> Hey Warren, >> >> 7009 states that you need to pass just the client_id for public clients, >> so if: >> >>> The client_id isn't necessary. >>> >> >> Then obviously something about 7009 needs to change. >> >> Whichever angle you look at, 7009 needs to change. >> >> On Thu, Sep 2, 2021 at 5:16 PM Warren Parad wrote: >> >>> Great, then let's fix 6749 not this one. The client_id isn't necessary. >>> >>> And then wouldn't 7009 not need to be changed because it already says >>> you don't need to pass any authorization for public clients? >>> >>> For credentialled client issued grants, refresh tokens, and access >>> tokens, these must not be able to be revoked without client credentials, so >>> using the refresh token or access token only for all other client types >>> must not be supported. >>> >>> On Thu, Sep 2, 2021, 08:52 Ash Narayanan >>> wrote: >>> >>>> Hi Warren, >>>> >>>> If you are referring to the client_id as arbitrary information, then >>>> the same would also be true for refresh requests to the token endpoint from >>>> public clients. As per 6749, you need to pass the client_id along with the >>>> refresh token. The client_id adds no additional security. >>>> >>>> But really, the whole point I've been trying to make from the start is >>>> that the token itself should be the only form of 'security' needed...as >>>> that's the point of OAuth. >>>> >>>> Regardless, 7009 needs to be made obsolete by a newer RFC. >>>> >>>> Ash >>>> >>>> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad wrote: >>>> >>>>> What's the point in passing arbitrary other information that is >>>>> already known by the AS and does not provide the level of security >>>>> necessary to prevent abuse of the revocation endpoint? >>>>> >>>>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan >>>>> wrote: >>>>> >>>>>> Hi Thomas, >>>>>> >>>>>> The approach you've suggested sounds good. Passing just the client_id >>>>>> along with the token and type (regardless of client type) would be >>>>>> consistent with how refresh_token requests are structured. As long as the >>>>>> new RFC obsoletes this one. >>>>>> >>>>>> Ash >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>> --000000000000f1fbcb05cafeebc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
According to this specification, a client's reque=
st must contain a
   valid client_id, in the case of a public client, or valid client
   credentials, in the case of a confidential client.

On Thu, Sep 2, 2021 at 6:22 PM Warren Parad <wparad@rhosys.ch> wrote:
Can you point out where it says that, I think I must of missed it= .

Warr= en Parad

Founder, CTO

S= ecure your user data with IAM authorization as a service. Implement=C2=A0Authress.


On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan <ashvinnarayanan@g= mail.com> wrote:
Hey Warr= en,

7009 states that you need to pass just the client_id= for public clients, so if:
The client_id isn't n= ecessary.

Then obviously something abou= t 7009 needs to change.

Whichever angle you look a= t, 7009 needs to change.=C2=A0

On Thu, Sep 2, 2021 at 5:16 PM Warren P= arad <wparad@rhosy= s.ch> wrote:
Great, then let's fix 6749 not this one. The client_id isn't = necessary.

And then woul= dn't 7009 not need to be changed because it already says you don't = need to pass any authorization for public clients?
<= br>
For credentialled client issued grants, refresh = tokens, and access tokens, these must not be able to be revoked without cli= ent credentials, so using the refresh token or access token only for all ot= her client types must not be supported.

On Thu,= Sep 2, 2021, 08:52 Ash Narayanan <ashvinnarayanan@gmail.com> wrote:
Hi Warren,

If you are= referring to the client_id as arbitrary information, then the same would a= lso be true for refresh requests to the token endpoint from public clients.= =C2=A0 As per 6749, you need to pass the client_id along with the refresh t= oken. The client_id adds no additional security.

B= ut really, the whole point I've been trying to make from the start is t= hat the token itself should be the only form of 'security' needed..= .as that's the point of OAuth.

Regardless, 700= 9 needs to be made obsolete by a newer RFC.

Ash

On Thu, Sep 2, 2021 at 4:41 PM Warren Parad <wparad@rhosys.ch> w= rote:
What's the point in p= assing arbitrary other information that is already known by the AS and does= not provide the level of security necessary to prevent abuse of the revoca= tion endpoint?

On Thu, Sep 2, 2021, 01:12 Ash Narayanan <ashvinn= arayanan@gmail.com> wrote:
Hi Thomas,

The approach you've suggested sounds go= od. Passing just the client_id along with the token and type (regardless of= client type) would be consistent with how refresh_token requests are struc= tured. As long as the new RFC obsoletes this one.

= Ash
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
--000000000000f1fbcb05cafeebc2-- From nobody Thu Sep 2 01:32:58 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795253A07EF for ; Thu, 2 Sep 2021 01:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTJRQsqYWDOv for ; Thu, 2 Sep 2021 01:32:49 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BD83A07E0 for ; Thu, 2 Sep 2021 01:32:49 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id a93so2358589ybi.1 for ; Thu, 02 Sep 2021 01:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pXex/MuE8orzlyTOWsKTICGp6hrndDmyRMYPaGQzyX4=; b=ILfh2+ZwhWTNBs7Ya9RzhBP9tWzzRfi31GuZ20F9FX10vJdkJnf6kwgMpOIXmMmc48 BXfhzbJQ+MaAdj9qgscjhAktFmlABszexMdB30rb+H75d+JlSQLpnkFprJzL8a+idUsI UV86GEsa+MKMmq53/AZ1ln2m3ZBL9FvyBWGgxV2YGb3uKVSWeHTBR4o13r6XQMeUDvmW 6B3sDSt02XPDLnX3mPyzxPpUVUzjf2yLfpA0WJ6Y1WbF4DwhMpTGvoD3H9qtz8le9YEM KhYu9R1Za1Nxs4+NHFP39LWEKdnIwnDpJN3hjPkgOiuidh5QSdZCEfIYd/dGYQS2+u3Z qsOQ== 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=pXex/MuE8orzlyTOWsKTICGp6hrndDmyRMYPaGQzyX4=; b=c3Fo+ElO4b9hP9WgTMqrYQ5I8vkvDxABLB0rnEldKvAYCg5xZ+a4gk+xUHdG+CGwhy rTp+3ObZqHBfI6lni1ATjfZH5BEAPG1oXQXl71LS1E6lGuOx1p+C1aNvfHFCeliNB2uL 95INidZjsKAvZuS75xT06DP77tOaUZCqlDxGe6RNHRji7PtDsZK3qITSBUhiy/I0kdrs 2nC4oI0IQSkf6Idxk3U9+EFDB2C3mBTW2FJwSVjl9zYA7fuQUrCpSbQP1D/tN1cgCN7i 0rfc67H6YaH9yVf/HJgY8MD4DMQN/bLXSwsnpI/ba7kJ2mAhHk2HRw8PiFfsf3A6oV/J d01g== X-Gm-Message-State: AOAM5329oRAKA/c/0q/RcsLOzHelP932Qiirc0aBac2OZZgBDFcbQBZd r6jQsr56UHiQSNYm9GatNsy4IcKtDMpFJimeG0xg X-Google-Smtp-Source: ABdhPJz3KqPF/Ht+LqoXCW8NU6xKLWJpT+5haiVTiQ17b2cSdXn3nIIhS1kOW5hRfzXLYcv2aFabbDSOfIT5EV12Vsk= X-Received: by 2002:a25:d049:: with SMTP id h70mr2786253ybg.182.1630571567356; Thu, 02 Sep 2021 01:32:47 -0700 (PDT) MIME-Version: 1.0 References: <20210822091434.93EFCF40723@rfc-editor.org> <80CE09CD-E462-4CB6-B4CC-EF4A7BE9F854@mit.edu> In-Reply-To: From: Warren Parad Date: Thu, 2 Sep 2021 10:32:36 +0200 Message-ID: To: Ash Narayanan Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="0000000000000db46405caff079f" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 08:32:56 -0000 --0000000000000db46405caff079f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah in 5. Security Considerations =F0=9F=91=8D Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Thu, Sep 2, 2021 at 10:25 AM Ash Narayanan wrote: > According to this specification, a client's request must contain a >> valid client_id, in the case of a public client, or valid client >> credentials, in the case of a confidential client. >> >> > > On Thu, Sep 2, 2021 at 6:22 PM Warren Parad wrote: > >> Can you point out where it says that, I think I must of missed it. >> >> Warren Parad >> >> Founder, CTO >> Secure your user data with IAM authorization as a service. Implement >> Authress . >> >> >> On Thu, Sep 2, 2021 at 10:21 AM Ash Narayanan >> wrote: >> >>> Hey Warren, >>> >>> 7009 states that you need to pass just the client_id for public clients= , >>> so if: >>> >>>> The client_id isn't necessary. >>>> >>> >>> Then obviously something about 7009 needs to change. >>> >>> Whichever angle you look at, 7009 needs to change. >>> >>> On Thu, Sep 2, 2021 at 5:16 PM Warren Parad wrote: >>> >>>> Great, then let's fix 6749 not this one. The client_id isn't necessary= . >>>> >>>> And then wouldn't 7009 not need to be changed because it already says >>>> you don't need to pass any authorization for public clients? >>>> >>>> For credentialled client issued grants, refresh tokens, and access >>>> tokens, these must not be able to be revoked without client credential= s, so >>>> using the refresh token or access token only for all other client type= s >>>> must not be supported. >>>> >>>> On Thu, Sep 2, 2021, 08:52 Ash Narayanan >>>> wrote: >>>> >>>>> Hi Warren, >>>>> >>>>> If you are referring to the client_id as arbitrary information, then >>>>> the same would also be true for refresh requests to the token endpoin= t from >>>>> public clients. As per 6749, you need to pass the client_id along wi= th the >>>>> refresh token. The client_id adds no additional security. >>>>> >>>>> But really, the whole point I've been trying to make from the start i= s >>>>> that the token itself should be the only form of 'security' needed...= as >>>>> that's the point of OAuth. >>>>> >>>>> Regardless, 7009 needs to be made obsolete by a newer RFC. >>>>> >>>>> Ash >>>>> >>>>> On Thu, Sep 2, 2021 at 4:41 PM Warren Parad wrote: >>>>> >>>>>> What's the point in passing arbitrary other information that is >>>>>> already known by the AS and does not provide the level of security >>>>>> necessary to prevent abuse of the revocation endpoint? >>>>>> >>>>>> On Thu, Sep 2, 2021, 01:12 Ash Narayanan >>>>>> wrote: >>>>>> >>>>>>> Hi Thomas, >>>>>>> >>>>>>> The approach you've suggested sounds good. Passing just the >>>>>>> client_id along with the token and type (regardless of client type)= would >>>>>>> be consistent with how refresh_token requests are structured. As lo= ng as >>>>>>> the new RFC obsoletes this one. >>>>>>> >>>>>>> Ash >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>> --0000000000000db46405caff079f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah in 5. Security Considerations=C2=A0=F0=9F=91=8D

Warren Parad

Founder, CTO

Secure your user data with IAM = authorization as a service. Implement=C2=A0Authress.


On Thu, Sep 2, 2= 021 at 10:25 AM Ash Narayanan <ashvinnarayanan@gmail.com> wrote:
Accordin=
g to this specification, a client's request must contain a
   valid client_id, in the case of a public client, or valid client
   credentials, in the case of a confidential client.

On Thu, Sep 2, 2021 at 6:22 PM Warren Parad <wparad@rhosys.ch> wrote:
Can you point = out where it says that, I think I must of missed it.

=

Warr= en Parad

Founder, CTO

Secure your user data with IAM authorization as a servic= e. Implement=C2=A0Authress= .


On Thu, Sep 2, 2021 at 10:21 AM Ash= Narayanan <ashvinnarayanan@gmail.com> wrote:
Hey Warren,

7009 states that you need to pass just the client_id for public clients, s= o if:
The client_id = isn't necessary.

Then obviously som= ething about 7009 needs to change.

Whichever angle= you look at, 7009 needs to change.=C2=A0

On Thu, Sep 2, 2021 at 5:16 = PM Warren Parad <w= parad@rhosys.ch> wrote:
Great, then let's fix= 6749 not this one. The client_id isn't necessary.

And then wouldn't 7009 not need to be ch= anged because it already says you don't need to pass any authorization = for public clients?

For = credentialled client issued grants, refresh tokens, and access tokens, thes= e must not be able to be revoked without client credentials, so using the r= efresh token or access token only for all other client types must not be su= pported.

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 2, 2021, 08:52 Ash Narayan= an <ashvi= nnarayanan@gmail.com> wrote:
Hi Warren,

If you a= re referring to the client_id as arbitrary information, then the same would= also be true for refresh requests to the token endpoint from public client= s.=C2=A0 As per 6749, you need to pass the client_id along with the refresh= token. The client_id adds no additional security.

But really, the whole point I've been trying to make from the start is= that the token itself should be the only form of 'security' needed= ...as that's the point of OAuth.

Regardless, 7= 009 needs to be made obsolete by a newer RFC.

Ash<= /div>

On Thu, Sep 2, 2021 at 4:41 PM Warren Parad <wparad@rhosys.ch>= wrote:
What's the point in passing arbitrary other information that = is already known by the AS and does not provide the level of security neces= sary to prevent abuse of the revocation endpoint?

On Thu, Sep 2, 2021, 01:12= Ash Narayanan <ashvinnarayanan@gmail.com> wrote:
Hi Thom= as,

The approach you've suggested sounds good. Passi= ng just the client_id along with the token and type (regardless of client t= ype) would be consistent with how refresh_token requests are structured. As= long as the new RFC obsoletes this one.

Ash
=
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
--0000000000000db46405caff079f-- From nobody Thu Sep 2 06:48:58 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5833A076F for ; Thu, 2 Sep 2021 06:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 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, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH0eBTCNddNS for ; Thu, 2 Sep 2021 06:48:47 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467133A0763 for ; Thu, 2 Sep 2021 06:48:45 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id mf2so4516246ejb.9 for ; Thu, 02 Sep 2021 06:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zsfWfdG0jUWrfGJIdKkf2VEv2okOBhv+wh2yPYKRTv8=; b=NK0gei0/EVQ06EUUZHpYXthJa6AAkwhNIjcbJRMtcbsXUj30kN86bF5Fy7L2K3o/Ne Dyu9jwGV+rW7JXa1dIeUSy0l13pqZaTkk9FwJZz7FWplocZgok6xoyACeGYjCSGhv0P+ eRhV1SRx+xIL/jxLJF6/uluckfhUOHbeYjH2DuyZq0T4X43FGGmzb/ZA+h2X7VsrBQMG IaKJDHi5Aw8cgPnZQYsuLvj/E+h0wiuASjccySBKpyC8o4Q5y7gqHpVka0qidoZpnMHB mGHdnMiW8/VfU8Yd0Q6C81V8AHzG1Lv+mVobV3YmTI9wgNUgZlco70300qWD5+SBg4N+ z3qg== 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=zsfWfdG0jUWrfGJIdKkf2VEv2okOBhv+wh2yPYKRTv8=; b=uAYIaxWCeBKeVHJFi/qS7UxzqAdOlj0aR/WLXUAKNaAyotMwelGh8UZGbWtCsyH/aD MMWHn4IM4VnIkGkq6ENCAJuqevgfFu6F5yGluFQ7XX1n3NMxRbTiUH724ulub+3lSuMZ NwSFaqUXBjj6g5hxLHQgHLXifs4lhy3/VNS8X8z+TfHKisCu4Sv0u6vIUBnuXbalOdmh x854n82dJmapLM0/m5nsJEV+FalDOVqbqBAgrAGhAw7KJfvPQF4FgwrUn3kRTchUCdKL uVdG/oWZdb+1qZ9jkuVbOvDv8RdgYdyy3p17mvfUHeZrT9Z8yIbkQ8rbiw+95AhMuREZ uTEw== X-Gm-Message-State: AOAM5323tKAkf2KNJvQFjh4LyFMfw4YbYIiDq8QA8gDxWq/rz6nMpIjk puJqlt1pOObC3otFg+MgfzdEBZASvaKu2dnSUqUutA== X-Google-Smtp-Source: ABdhPJwuO0L5RGYWyqzJ+ESQOCQWDi8d9t1UsGRxebZT4+Vb6DkExz6ASls9h6pQL/DdFKVJUb61zkvLY6jcdwUOS2w= X-Received: by 2002:a17:906:9708:: with SMTP id k8mr3884988ejx.399.1630590523477; Thu, 02 Sep 2021 06:48:43 -0700 (PDT) MIME-Version: 1.0 References: <7F1D49D6-C39B-45AB-8AA0-D399802B882E@lodderstedt.net> In-Reply-To: From: Domingos Creado Date: Thu, 2 Sep 2021 10:48:32 -0300 Message-ID: To: Ash Narayanan Cc: Torsten Lodderstedt , IETF oauth WG Content-Type: multipart/alternative; boundary="000000000000ed211305cb037011" Archived-At: Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7009 (6663) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 13:48:54 -0000 --000000000000ed211305cb037011 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ash, my understanding of a errata is when there is something technically wrong with the document. Your point is clear: requiring the client id on the revocation endpoint for public clients does not protect the endpoint is valid. You might say that is a point less to require it and might cause people to assume that the endpoint is protected. but I don't think we can say that is an error as I guess that was already in mind when the spec was created. On Tue, Aug 31, 2021 at 7:13 AM Ash Narayanan wrote: > Hi Torsten, > > Thanks for clarifying. The errata system allows for two types of errata, > editorial and technical. I selected technical when I submitted this > particular one. Things like typos and ambiguities sound like editorial to > me, unless I'm mistaken. > > I'd be fine with submitting a new RFC so as to not change the security > assumptions of this spec, though I'm not sure what then would be the > purpose of a technical errata? > > Cheers, > Ash > > On Tue, Aug 31, 2021 at 5:29 PM Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi Ash, >> >> Am 31.08.2021 um 02:42 schrieb Ash Narayanan = : >> >> Hi Dick, >> >> >The access token represents the authorization to access the resource(s) >> -- >> >it does not represent the authorization to manipulate tokens. >> >> Anything for which the client must have an access token to access is a >> protected resource. In order to revoke a token, the client must have the >> associated access token to begin with, hence a protected resource. If no= t a >> protected resource, it is implied anyone can access it, and the OAuth sp= ec >> makes no assertions about where a protected resource must be located so >> there's no reason it can't be on the AS as well. >> >> Emond describes it quite neatly: >> >> I see it like returning a key when you no longer need access to a >> building. >> >> The fact that you hold the key should be enough for you to be able to >> return it. >> >> So you shouldn't be returning a key you never had. >> >> Anything for which you *may* use a client_secret if you have one or not >> if you don't is generally a red flag. In RFC 7009 as I've pointed out, t= he >> client_id is being used as a security measure as it's part of the >> authentication header. Furthermore, it also mentions an attacker >> *guessing* it (in addition to the token). The client_id is by no means a >> secure item on a non-confidential client such as an SPA. >> >> Also you say: >> > Changing the spec would change the security assumptions that existing >> deployments have made. >> >> Isn't that the nature of the business? Or are you implying that no >> deployment should ever change even if improvements are found? >> >> >> Certainly not. However, an errata is not supposed to change the security >> assumptions of a spec. It is supposed to fix typos and clarify ambiguiti= es. >> Changing the security assumptions or applying other normative changes is >> subject to new RFCs replacing the older ones. >> >> So from my perspective, your inquiry exceeds the scope of an errata. >> >> best regards, >> Torsten. >> >> >> Ash >> >> >> >Hey Emond >> > >> >The access token represents the authorization to access the resource(s) >> -- >> >it does not represent the authorization to manipulate tokens. The clien= t >> >credentials are used for token management. While your implementation ma= y >> be >> >ok with using the access token to revoke itself, it is not the security >> >model represented by the specification. Changing the spec would change >> the >> >security assumptions that existing deployments have made. >> > >> >As noted in your response, the CLI has access to the client credentials >> to >> >revoke. Besides convenience, it is not clear to me why you would not wa= nt >> >to require the client credentials -- but it is your implementation -- y= ou >> >can make your own decisions where and if you want to be compliant. >> > >> >Warren: an interesting idea to provide more context on this in OAuth 2.= 1. >> > >> >/Dick >> >=E1=90=A7 >> > >> >On Tue, Aug 24, 2021 at 8:10 AM Emond Papegaaij < >> emond.papegaaij@gmail.com> >> >wrote: >> > >> >> On Tue, Aug 24, 2021 at 12:14 PM Warren Parad >> wrote: >> >> >> >>> I think it is worth pointing out, if we were to agree with the errat= a, >> >>> that this particular use case probably isn't relevant: >> >>> >> >>> Our client in this case was a command line tool, which only requests >> the >> >>>> client credentials on login. It then fetches an access token and >> stores >> >>>> this locally. The client credentials are not stored by default. >> >>> >> >>> >> >>> Unless I misunderstand, I'll take "client credentials" to mean clien= t >> Id >> >>> and client credentials via a client credentials grant. And therefore= , >> is >> >>> not the correct flow to be used in a command line tool. Client >> credentials >> >>> are used in private when there are many user agents that could conne= ct >> >>> through it, I would not recommend this as the solution here, and eve= n >> if it >> >>> were, you would indeed have access to the client id and secret, so i= t >> would >> >>> not be a problem to use them to revoke the token. >> >>> >> >> >> >> The CLI-tool actually supports both a 3-legged (via the device >> >> authorization grant) and a 2-legged flow (via the client credentials >> >> grant). It depends on the use case which one is appropriate. In the >> case of >> >> a user logging in to access the application via the CLI, it clearly i= s >> the >> >> 3-legged flow, however when the CLI is used in a script that runs >> without >> >> user interaction, it's the 2-legged flow. In this later case, the >> script >> >> often fetches the credentials from some store, uses them to acquire a= n >> >> access token, does it job, and revokes the token. Naturally, it can >> fetch >> >> the credentials a second time to revoke the token, but I really don't >> see >> >> the point in this case. The client merely indicates it is done with t= he >> >> token and it can now be revoked. It is good practice to discard any >> >> credentials when you are done with them to minimize the chance of >> abuse. >> >> However, requiring the client authentication to revoke the token, >> really >> >> complicates this case and will probably lead to scripts not revoking >> the >> >> token. >> >> >> >> >> >>> However, I believe there is something fundamentally broke here, >> because >> >>> there are two use cases which are in conflict with each other: >> >>> >> >>> - I as a user, at any time want to revoke one of, access token, >> >>> refresh token, or granted scopes associated with my identity by >> directly >> >>> communicating with an AS. I never want to make this request >> through a >> >>> client, and more specifically, I never want a client to determine >> whether >> >>> or not I'm allowed to revoke these. >> >>> - I as a user, at no time want to allow a client, for whom I did >> not >> >>> give permission to revoke my refresh token nor revoke granted >> scopes. It >> >>> should not be the case that one client sharing the token with >> another >> >>> client (either intentionally or accidentally) would be allowed to >> change >> >>> the requested scopes nor make decisions about the validity of my >> current >> >>> access token or delegated refresh token. >> >>> >> >>> Given the latter we see that it must be the case that refresh tokens= , >> >>> access tokens, and associated grants MUST NOT be allowed to be revok= ed >> >>> without client authentication. This means that the original RFC is >> indeed >> >>> correct, and that the errata is not. But, this does not enable the >> former >> >>> case nor encourage a solution that works in scope of retaining >> control over >> >>> resources that the user agent owns. However, it is worth mentioning >> that it >> >>> doesn't prevent, as it still allows an AS to implement additional >> >>> mechanisms for direct user revocation, if desired. >> >>> >> >>> That being said I would be in favor of enumerating a *flow* to safel= y >> >>> instruct the AS to revoke directly by the user, but it cannot be don= e >> by >> >>> amending the revocation endpoint. >> >>> >> >> >> >> I don't fully understand your statement here. As far as I understand >> the >> >> token revocation endpoint, it is an endpoint specifically for the >> client to >> >> be used when it no longer needs the token. The client can simply >> discard >> >> the tokens, but it is cleaner to inform the AS about this fact and >> allow >> >> the AS to cleanup its resources as well. It is in no way an endpoint >> to be >> >> used by the resource owner to revoke access for certain clients. I se= e >> it >> >> like returning a key when you no longer need access to a building. Th= e >> fact >> >> that you hold the key should be enough for you to be able to return i= t. >> >> >> >> I do want to point out that the spec for bearer tokens states: "A >> security >> >> token with the property that any party in possession of the token (a >> >> "bearer") can use the token in any way that any other party in >> possession >> >> of it can." Clients should IMHO not be exchanging tokens with another >> party >> >> unless they really trust this other party, in which case they should >> also >> >> trust this party not to revoke the tokens when not agreed upon. If an= y >> >> malicious party would get hold of my tokens, I wish they would only u= se >> >> them to revoke them. A leaked token should be revoked anyway. One cou= ld >> >> even argue that the grant for the original client should also be >> revoked in >> >> this case as well, because it is clearly broken. >> >> >> >> Best regards, >> >> Emond Papegaaij >> >> >> >> >> >> >> >>> On Tue, Aug 24, 2021 at 9:44 AM Emond Papegaaij < >> >>> emond.papegaaij@gmail.com> wrote: >> >>> >> >>>> On Mon, Aug 23, 2021 at 9:42 PM Justin Richer >> wrote: >> >>>> >> >>>>> I personally don=E2=80=99t agree with this errata. Token Revocatio= n was >> never >> >>>>> meant to act as a protected resource, but rather as a function of >> the AS. >> >>>>> The client is known to the AS and so authentication is expected >> here. >> >>>>> >> >>>> >> >>>> We ran into this very issue some time ago. Our client in this case >> was a >> >>>> command line tool, which only requests the client credentials on >> login. It >> >>>> then fetches an access token and stores this locally. The client >> >>>> credentials are not stored by default. The current spec required us >> to >> >>>> request the client credentials to revoke the access token on logout= . >> >>>> Personally, I see no point in requiring the the client to >> authenticate, it >> >>>> already possesses an access token, which it can use for whatever it >> wants >> >>>> to and the possession of the token should be enough evidence that t= he >> >>>> client previously authenticated. Revoking the token seems to be the >> least >> >>>> harmful one can do with a token. >> >>>> >> >>>> For more information see: >> >>>> >> https://mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I/ >> >> >>>> >> >>>> Best regards, >> >>>> Emond Papegaaij >> >>>> >> >>>> >> >>>> >> >>>>> > On Aug 22, 2021, at 5:14 AM, RFC Errata System < >> >>>>> rfc-editor@rfc-editor.org> wrote: >> >>>>> > >> >>>>> > The following errata report has been submitted for RFC7009, >> >>>>> > "OAuth 2.0 Token Revocation". >> >>>>> > >> >>>>> > -------------------------------------- >> >>>>> > You may review the report below and at: >> >>>>> > https://www.rfc-editor.org/errata/eid6663 >> >> >>>>> > >> >>>>> > -------------------------------------- >> >>>>> > Type: Technical >> >>>>> > Reported by: Ashvin Narayanan >> >>>>> > >> >>>>> > Section: 2.1 >> >>>>> > >> >>>>> > Original Text >> >>>>> > ------------- >> >>>>> > The client constructs the request by including the following >> >>>>> > parameters using the "application/x-www-form-urlencoded" forma= t >> in >> >>>>> > the HTTP request entity-body: >> >>>>> > >> >>>>> > token REQUIRED. The token that the client wants to get >> revoked. >> >>>>> > >> >>>>> > token_type_hint OPTIONAL. A hint about the type of the token >> >>>>> > submitted for revocation. Clients MAY pass this >> parameter >> >>>>> in >> >>>>> > order to help the authorization server to optimize the >> token >> >>>>> > lookup. If the server is unable to locate the token >> using >> >>>>> > the given hint, it MUST extend its search across all o= f >> its >> >>>>> > supported token types. An authorization server MAY >> ignore >> >>>>> > this parameter, particularly if it is able to detect t= he >> >>>>> > token type automatically. This specification defines >> two >> >>>>> > such values: >> >>>>> > >> >>>>> > * access_token: An access token as defined in [RFC6749= ], >> >>>>> > Section 1.4 >> >>>>> > >> >>>>> > * refresh_token: A refresh token as defined in >> [RFC6749], >> >>>>> > Section 1.5 >> >>>>> > >> >>>>> > Specific implementations, profiles, and extensions of >> this >> >>>>> > specification MAY define other values for this paramet= er >> >>>>> > using the registry defined in Section 4.1.2. >> >>>>> > >> >>>>> > The client also includes its authentication credentials as >> described >> >>>>> > in Section 2.3. of [RFC6749]. >> >>>>> > >> >>>>> > For example, a client may request the revocation of a refresh >> token >> >>>>> > with the following request: >> >>>>> > >> >>>>> > POST /revoke HTTP/1.1 >> >>>>> > Host: server.example.com >> >> >>>>> > Content-Type: application/x-www-form-urlencoded >> >>>>> > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW >> >>>>> > >> >>>>> > token=3D45ghiukldjahdnhzdauz&token_type_hint=3Drefresh_token >> >>>>> > >> >>>>> > The authorization server first validates the client credential= s >> (in >> >>>>> > case of a confidential client) and then verifies whether the >> token >> >>>>> > was issued to the client making the revocation request. If th= is >> >>>>> > validation fails, the request is refused and the client is >> informed >> >>>>> > of the error by the authorization server as described below. >> >>>>> > >> >>>>> > Corrected Text >> >>>>> > -------------- >> >>>>> > The client calls the revocation endpoint using an HTTP >> >>>>> > POST [RFC7231] request with the following parameters sent as >> >>>>> > "application/x-www-form-urlencoded" data in the request body: >> >>>>> > >> >>>>> > token REQUIRED. The token that the client wants to get >> revoked. >> >>>>> > >> >>>>> > token_type_hint OPTIONAL. A hint about the type of the token >> >>>>> > submitted for revocation. Clients MAY pass this >> parameter >> >>>>> in >> >>>>> > order to help the authorization server to optimize the >> token >> >>>>> > lookup. If the server is unable to locate the token >> using >> >>>>> > the given hint, it MUST extend its search across all o= f >> its >> >>>>> > supported token types. An authorization server MAY >> ignore >> >>>>> > this parameter, particularly if it is able to detect t= he >> >>>>> > token type automatically. This specification defines >> two >> >>>>> > such values: >> >>>>> > >> >>>>> > * access_token: An access token as defined in [RFC6749= ], >> >>>>> > Section 1.4 >> >>>>> > >> >>>>> > * refresh_token: A refresh token as defined in >> [RFC6749], >> >>>>> > Section 1.5 >> >>>>> > >> >>>>> > Specific implementations, profiles, and extensions of >> this >> >>>>> > specification MAY define other values for this paramet= er >> >>>>> > using the registry defined in Section 4.1.2. >> >>>>> > >> >>>>> > The client MUST also include in the request, the access token = it >> >>>>> received >> >>>>> > from the authorization server. It must do so in the same way a= s >> it >> >>>>> would >> >>>>> > when accessing a protected resource, as describe in [RFC6749], >> >>>>> Section 7. >> >>>>> > >> >>>>> > The following is a non-normative example request in which the >> >>>>> client uses >> >>>>> > its access token to revoke the associated refresh token: >> >>>>> > >> >>>>> > POST /revoke HTTP/1.1 >> >>>>> > Host: server.example.com >> >> >>>>> > Content-Type: application/x-www-form-urlencoded >> >>>>> > Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW >> >>>>> > >> >>>>> > token=3D45ghiukldjahdnhzdauz&token_type_hint=3Drefresh_token >> >>>>> > >> >>>>> > The following is a non-normative example request in which the >> >>>>> client uses >> >>>>> > its access token to revoke the same access token: >> >>>>> > >> >>>>> > POST /revoke HTTP/1.1 >> >>>>> > Host: server.example.com >> >> >>>>> > Content-Type: application/x-www-form-urlencoded >> >>>>> > Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW >> >>>>> > >> >>>>> > >> token=3DczZCaGRSa3F0MzpnWDFmQmF0M2JW&token_type_hint=3Daccess_token >> >>>>> > >> >>>>> > The authorization server MUST validate the access token used b= y >> >>>>> the >> >>>>> > client to authorize its call to the revocation endpoint, >> including >> >>>>> > ensuring that it is not expired or revoked. >> >>>>> > Additionally, the authorization server MUST also validate >> whether >> >>>>> the >> >>>>> > access token used for authorization is part of the same grant >> as >> >>>>> the >> >>>>> > token being revoked. If validation fails, the request is >> refused >> >>>>> and >> >>>>> > the client is informed of the error by the authorization serve= r. >> >>>>> > In the case of a bearer token, the authorization server SHOULD >> >>>>> respond >> >>>>> > with an HTTP 401 code as described in OAuth 2.0 Bearer Token >> Usage >> >>>>> > [RFC6750], Section 3. >> >>>>> > Errors based on other types of tokens are beyond the scope of >> this >> >>>>> > specification. >> >>>>> > >> >>>>> > >> >>>>> > Notes >> >>>>> > ----- >> >>>>> > It appears as though the authors of RFC7009 have failed to >> consider >> >>>>> that requests to revoke are likely to come from non-confidential >> clients >> >>>>> and such, would lack authentication credentials. Regardless of the >> type of >> >>>>> client however, authentication should not be required. The OAuth 2= .0 >> >>>>> specification (RFC6749) does not specify verifying that the access >> token >> >>>>> belongs to the client accessing protected resources, of which >> revocation is >> >>>>> one. It is the role of the access token alone to signify >> authorization >> >>>>> required to make requests to protected resources. If this is an >> issue for >> >>>>> revocation, then it is an issue for all protected resources and >> counter >> >>>>> measures may be proposed in a separate RFC rather than broadening >> the scope >> >>>>> of this particular RFC. As per the original text itself, "This >> >>>>> specification in general does not intend to provide countermeasure= s >> against >> >>>>> token theft and abuse." Additionally, "If an attacker is able to >> >>>>> successfully guess a public client's client_id and one of their to= k >> >>>>> > ens, or a private client's credentials and one of their tokens, >> they >> >>>>> could do much worse damage by using the token elsewhere than by >> revoking >> >>>>> it. If they chose to revoke the token, the legitimate client will >> lose its >> >>>>> authorization grant and will need to prompt the user again. No >> further >> >>>>> damage is done and the guessed token is now worthless." >> >>>>> > Note that the client_id is not meant to be private information t= o >> >>>>> begin with, so relying on an attacker "guessing" it should not be >> seen as a >> >>>>> security countermeasure. This section of RFC7009 will be reference= d >> in a >> >>>>> subsequent errata. >> >>>>> > >> >>>>> > 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 necessar= y. >> >>>>> > >> >>>>> > -------------------------------------- >> >>>>> > RFC7009 (draft-ietf-oauth-revocation-11) >> >>>>> > -------------------------------------- >> >>>>> > Title : OAuth 2.0 Token Revocation >> >>>>> > Publication Date : August 2013 >> >>>>> > Author(s) : T. Lodderstedt, Ed., S. Dronia, M. Scurtes= cu >> >>>>> > Category : PROPOSED STANDARD >> >>>>> > Source : Web Authorization Protocol >> >>>>> > Area : Security >> >>>>> > Stream : IETF >> >>>>> > Verifying Party : IESG >> >>>>> > >> >>>>> > _______________________________________________ >> >>>>> > OAuth mailing list >> >>>>> > OAuth@ietf.org >> >>>>> > https://www.ietf.org/mailman/listinfo/oauth >> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> OAuth mailing list >> >>>>> OAuth@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/oauth >> >> >>>>> >> >>>> _______________________________________________ >> >>>> 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.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oau= th&source=3Dgmail-imap&ust=3D1630975362000000&usg=3DAOvVaw0SBRIZ3JVu9V2FyhP= 0VRFL >> >> >> _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000ed211305cb037011 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ash,

my understanding of = a errata is when there is something technically wrong with the document.
Your point is clear: requiring the client id on the revocation endp= oint for public clients does not protect the endpoint is valid.
<= /div>
You might say that is a point less to require it and might cause = people to assume that the endpoint is protected.
but I don't= think we can say that is an error as I guess that was already in mind when= the spec was created.


On Tue, Aug 31, 2021 at 7:13 AM = Ash Narayanan <ashvinnaraya= nan@gmail.com> wrote:
Hi Torsten,

Tha= nks for clarifying. The errata system allows for two types of errata, edito= rial and technical. I selected technical when I submitted this particular o= ne. Things like typos and ambiguities sound like editorial to me, unless I&= #39;m mistaken.=C2=A0

I'd be fine with submitt= ing a new RFC so as to not change the security assumptions of this spec, th= ough I'm not sure what then would be the purpose of a technical errata?=

Cheers,
Ash

On Tue, Aug 31, 2= 021 at 5:29 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi Ash,

Am 31.08.= 2021 um 02:42 schrieb Ash Narayanan <ashvinnarayanan@gmail.com>:

Hi Dick,

>The access token represent= s the authorization to access the resource(s) --
>it does not represe= nt the authorization to manipulate tokens.=C2=A0

Anything for which = the client must have an access token to access is a protected resource. In = order to revoke a token, the client must have the associated access token t= o begin with, hence a protected resource. If not a protected resource, it i= s implied anyone can access it, and the OAuth spec makes no assertions abou= t where a protected resource must be located so there's no reason it ca= n't be on the AS as well.

Emond describes it quite neatly= :
>> I see it like returning a key when you no longer need access = to a building.
>> The fact that you hold the key should be enough= for you to be able to return it.

So you shouldn't be returning = a key you never had.

Anything for which you=C2=A0may=C2=A0use= a client_secret if you have one or not if you don't is generally a red= flag. In RFC 7009 as I've pointed out, the client_id is being used as = a security measure as it's part of the authentication header. Furthermo= re, it also mentions an attacker guessing it (in addition to the tok= en). The client_id is by no means a secure item on a non-confidential clien= t such as an SPA.

Also you say:
> Changing the spec would chan= ge the=C2=A0security assumptions that existing deployments have made.
Isn't that the nature of the business? Or are you implying that no de= ployment should ever change even if improvements are found?
=

Certainly not. However, an errata i= s not supposed to change the security assumptions of a spec. It is supposed= to fix typos and clarify ambiguities. Changing the security assumptions or= applying other normative changes is subject to new RFCs replacing the olde= r ones.=C2=A0

So from my perspective, your inquiry= exceeds the scope of an errata.=C2=A0

best regard= s,
Torsten.=C2=A0


Ash


>Hey Emond
>
>Th= e access token represents the authorization to access the resource(s) -->it does not represent the authorization to manipulate tokens. The clie= nt
>credentials are used for token management. While your implementat= ion may be
>ok with using the access token to revoke itself, it is no= t the security
>model represented by the specification. Changing the = spec would change the
>security assumptions that existing deployments= have made.
>
>As noted in your response, the CLI has access to= the client credentials to
>revoke. Besides convenience, it is not cl= ear to me why you would not want
>to require the client credentials -= - but it is your implementation -- you
>can make your own decisions w= here and if you want to be compliant.
>
>Warren: an interesting= idea to provide more context on this in OAuth 2.1.
>
>/Dick>=E1=90=A7
>
>On Tue, Aug 24, 2021 at 8:10 AM Emond Papegaa= ij <emond= .papegaaij@gmail.com>
>wrote:
>
>> On Tue, Aug = 24, 2021 at 12:14 PM Warren Parad <wparad@rhosys.ch> wrote:
>>
>>>= ; I think it is worth pointing out, if we were to agree with the errata,>>> that this particular use case probably isn't relevant:>>>
>>> Our client in this case was a command line to= ol, which only requests the
>>>> client credentials on login= . It then fetches an access token and stores
>>>> this local= ly. The client credentials are not stored by default.
>>>
&g= t;>>
>>> Unless I misunderstand, I'll take "clie= nt credentials" to mean client Id
>>> and client credentia= ls via a client credentials grant. And therefore, is
>>> not th= e correct flow to be used in a command line tool. Client credentials
>= ;>> are used in private when there are many user agents that could co= nnect
>>> through it, I would not recommend this as the solutio= n here, and even if it
>>> were, you would indeed have access t= o the client id and secret, so it would
>>> not be a problem to= use them to revoke the token.
>>>
>>
>> The = CLI-tool actually supports both a 3-legged (via the device
>> auth= orization grant) and a 2-legged flow (via the client credentials
>>= ; grant). It depends on the use case which one is appropriate. In the case = of
>> a user logging in to access the application via the CLI, it = clearly is the
>> 3-legged flow, however when the CLI is used in a= script that runs without
>> user interaction, it's the 2-legg= ed flow. In this later case, the script
>> often fetches the crede= ntials from some store, uses them to acquire an
>> access token, d= oes it job, and revokes the token. Naturally, it can fetch
>> the = credentials a second time to revoke the token, but I really don't see>> the point in this case. The client merely indicates it is done w= ith the
>> token and it can now be revoked. It is good practice to= discard any
>> credentials when you are done with them to minimiz= e the chance of abuse.
>> However, requiring the client authentica= tion to revoke the token, really
>> complicates this case and will= probably lead to scripts not revoking the
>> token.
>>>>
>>> However, I believe there is something fundamenta= lly broke here, because
>>> there are two use cases which are i= n conflict with each other:
>>>
>>> =C2=A0 =C2=A0- = I as a user, at any time want to revoke one of, access token,
>>&g= t; =C2=A0 =C2=A0refresh token, or granted scopes associated with my identit= y by directly
>>> =C2=A0 =C2=A0communicating with an AS. I neve= r want to make this request through a
>>> =C2=A0 =C2=A0client, = and more specifically, I never want a client to determine whether
>&g= t;> =C2=A0 =C2=A0or not I'm allowed to revoke these.
>>>= =C2=A0 =C2=A0- I as a user, at no time want to allow a client, for whom I = did not
>>> =C2=A0 =C2=A0give permission to revoke my refresh t= oken nor revoke granted scopes. It
>>> =C2=A0 =C2=A0should not = be the case that one client sharing the token with another
>>> = =C2=A0 =C2=A0client (either intentionally or accidentally) would be allowed= to change
>>> =C2=A0 =C2=A0the requested scopes nor make decis= ions about the validity of my current
>>> =C2=A0 =C2=A0access t= oken or delegated refresh token.
>>>
>>> Given the = latter we see that it must be the case that refresh tokens,
>>>= access tokens, and associated grants MUST NOT be allowed to be revoked
= >>> without client authentication. This means that the original RF= C is indeed
>>> correct, and that the errata is not. But, this = does not enable the former
>>> case nor encourage a solution th= at works in scope of retaining control over
>>> resources that = the user agent owns. However, it is worth mentioning that it
>>>= ; doesn't prevent, as it still allows an AS to implement additional
= >>> mechanisms for direct user revocation, if desired.
>>= >
>>> That being said I would be in favor of enumerating a *= flow* to safely
>>> instruct the AS to revoke directly by the u= ser, but it cannot be done by
>>> amending the revocation endpo= int.
>>>
>>
>> I don't fully understand y= our statement here. As far as I understand the
>> token revocation= endpoint, it is an endpoint specifically for the client to
>> be = used when it no longer needs the token. The client can simply discard
&g= t;> the tokens, but it is cleaner to inform the AS about this fact and a= llow
>> the AS to cleanup its resources as well. It is in no way a= n endpoint to be
>> used by the resource owner to revoke access fo= r certain clients. I see it
>> like returning a key when you no lo= nger need access to a building. The fact
>> that you hold the key = should be enough for you to be able to return it.
>>
>> I= do want to point out that the spec for bearer tokens states: "A secur= ity
>> token with the property that any party in possession of the= token (a
>> "bearer") can use the token in any way that= any other party in possession
>> of it can." Clients should = IMHO not be exchanging tokens with another party
>> unless they re= ally trust this other party, in which case they should also
>> tru= st this party not to revoke the tokens when not agreed upon. If any
>= > malicious party would get hold of my tokens, I wish they would only us= e
>> them to revoke them. A leaked token should be revoked anyway.= One could
>> even argue that the grant for the original client sh= ould also be revoked in
>> this case as well, because it is clearl= y broken.
>>
>> Best regards,
>> Emond Papegaaij=
>>
>>
>>
>>> On Tue, Aug 24, 2021 a= t 9:44 AM Emond Papegaaij <
>>> emond.papegaaij@gmail.com> wrote:=
>>>
>>>> On Mon, Aug 23, 2021 at 9:42 PM Justin= Richer <jricher@mi= t.edu> wrote:
>>>>
>>>>> I personal= ly don=E2=80=99t agree with this errata. Token Revocation was never
>= >>>> meant to act as a protected resource, but rather as a func= tion of the AS.
>>>>> The client is known to the AS and s= o authentication is expected here.
>>>>>
>>>&= gt;
>>>> We ran into this very issue some time ago. Our clie= nt in this case was a
>>>> command line tool, which only req= uests the client credentials on login. It
>>>> then fetches = an access token and stores this locally. The client
>>>> cre= dentials are not stored by default. The current spec required us to
>= >>> request the client credentials to revoke the access token on l= ogout.
>>>> Personally, I see no point in requiring the the = client to authenticate, it
>>>> already possesses an access = token, which it can use for whatever it wants
>>>> to and th= e possession of the token should be enough evidence that the
>>>= ;> client previously authenticated. Revoking the token seems to be the l= east
>>>> harmful one can do with a token.
>>>&g= t;
>>>> For more information see:
>>>> https:/= /mailarchive.ietf.org/arch/msg/oauth/7qxGcptE-uzA5WQaxnzGMdSqb2I/
&g= t;>>>
>>>> Best regards,
>>>> Emond = Papegaaij
>>>>
>>>>
>>>>
&g= t;>>>> > On Aug 22, 2021, at 5:14 AM, RFC Errata System <=
>>>>> rfc-editor@rfc-editor.org> wrote:
>>>>&g= t; >
>>>>> > The following errata report has been s= ubmitted for RFC7009,
>>>>> > "OAuth 2.0 Token Re= vocation".
>>>>> >
>>>>> > -= -------------------------------------
>>>>> > You may = review the report below and at:
>>>>> > https://www.rfc-editor.org/errata/eid6663<= br>>>>>> >
>>>>> > -----------------= ---------------------
>>>>> > Type: Technical
>&= gt;>>> > Reported by: Ashvin Narayanan <ashvinnarayanan@gmail.com>= ;
>>>>> >
>>>>> > Section: 2.1>>>>> >
>>>>> > Original Text
&g= t;>>>> > -------------
>>>>> > The clie= nt constructs the request by including the following
>>>>>= ; > =C2=A0 parameters using the "application/x-www-form-urlencoded&= quot; format in
>>>>> > =C2=A0 the HTTP request entity= -body:
>>>>> >
>>>>> > =C2=A0 tok= en =C2=A0 REQUIRED.=C2=A0 The token that the client wants to get revoked.>>>>> >
>>>>> > =C2=A0 token_type_= hint =C2=A0OPTIONAL.=C2=A0 A hint about the type of the token
>>&g= t;>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 submitted for revocation= .=C2=A0 Clients MAY pass this parameter
>>>>> in
>&= gt;>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 order to help the a= uthorization server to optimize the token
>>>>> > =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lookup.=C2=A0 If the server is unable to lo= cate the token using
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 the given hint, it MUST extend its search across all of its
&= gt;>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supported token= types.=C2=A0 An authorization server MAY ignore
>>>>> &g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this parameter, particularly if it is= able to detect the
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 token type automatically.=C2=A0 This specification defines two>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such values:=
>>>>> >
>>>>> > =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * access_token: An access token as defined in [RFC6749= ],
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S= ection 1.4
>>>>> >
>>>>> > =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 * refresh_token: A refresh token as defined in= [RFC6749],
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 Section 1.5
>>>>> >
>>>>> &g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specific implementations, profiles, a= nd extensions of this
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 specification MAY define other values for this parameter
>= >>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 using the registry= defined in Section 4.1.2.
>>>>> >
>>>>= > > =C2=A0 The client also includes its authentication credentials as= described
>>>>> > =C2=A0 in Section 2.3. of [RFC6749]= .
>>>>> >
>>>>> > =C2=A0 For exam= ple, a client may request the revocation of a refresh token
>>>= >> > =C2=A0 with the following request:
>>>>> &g= t;
>>>>> > =C2=A0 =C2=A0 POST /revoke HTTP/1.1
>= >>>> > =C2=A0 =C2=A0 Host: server= .example.com
>>>>> > =C2=A0 =C2=A0 Content-Type: a= pplication/x-www-form-urlencoded
>>>>> > =C2=A0 =C2=A0= Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>>>> = >
>>>>> > =C2=A0 =C2=A0 token=3D45ghiukldjahdnhzdau= z&token_type_hint=3Drefresh_token
>>>>> >
>&= gt;>>> > =C2=A0 The authorization server first validates the cl= ient credentials (in
>>>>> > =C2=A0 case of a confiden= tial client) and then verifies whether the token
>>>>> &g= t; =C2=A0 was issued to the client making the revocation request.=C2=A0 If = this
>>>>> > =C2=A0 validation fails, the request is r= efused and the client is informed
>>>>> > =C2=A0 of th= e error by the authorization server as described below.
>>>>= > >
>>>>> > Corrected Text
>>>>&g= t; > --------------
>>>>> > The client calls the re= vocation endpoint using an HTTP
>>>>> > =C2=A0 POST [R= FC7231] request with the following parameters sent as
>>>>&g= t; > =C2=A0 "application/x-www-form-urlencoded" data in the re= quest body:
>>>>> >
>>>>> > =C2= =A0 token =C2=A0 REQUIRED.=C2=A0 The token that the client wants to get rev= oked.
>>>>> >
>>>>> > =C2=A0 toke= n_type_hint =C2=A0OPTIONAL.=C2=A0 A hint about the type of the token
>= ;>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 submitted for rev= ocation.=C2=A0 Clients MAY pass this parameter
>>>>> in>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 order to hel= p the authorization server to optimize the token
>>>>> &g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lookup.=C2=A0 If the server is unable= to locate the token using
>>>>> > =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 the given hint, it MUST extend its search across all of i= ts
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 supporte= d token types.=C2=A0 An authorization server MAY ignore
>>>>= > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this parameter, particularly i= f it is able to detect the
>>>>> > =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 token type automatically.=C2=A0 This specification define= s two
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such = values:
>>>>> >
>>>>> > =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 * access_token: An access token as defined in [= RFC6749],
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Section 1.4
>>>>> >
>>>>> >= ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * refresh_token: A refresh token as de= fined in [RFC6749],
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Section 1.5
>>>>> >
>>>&= gt;> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specific implementations, p= rofiles, and extensions of this
>>>>> > =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 specification MAY define other values for this paramet= er
>>>>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 using th= e registry defined in Section 4.1.2.
>>>>> >
>&g= t;>>> > =C2=A0 The client MUST also include in the request, the= access token it
>>>>> received
>>>>> &= gt; =C2=A0 from the authorization server. It must do so in the same way as = it
>>>>> would
>>>>> > =C2=A0 when a= ccessing a protected resource, as describe in [RFC6749],
>>>>= ;> Section 7.
>>>>> >
>>>>> > = =C2=A0 The following is a non-normative example request in which the
>= ;>>>> client uses
>>>>> > =C2=A0 its acces= s token to revoke the associated refresh token:
>>>>> >= ;
>>>>> > =C2=A0 =C2=A0 POST /revoke HTTP/1.1
>&= gt;>>> > =C2=A0 =C2=A0 Host: server.= example.com
>>>>> > =C2=A0 =C2=A0 Content-Type: ap= plication/x-www-form-urlencoded
>>>>> > =C2=A0 =C2=A0 = Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>>>> = >
>>>>> > =C2=A0 =C2=A0 token=3D45ghiukldjahdnhzdau= z&token_type_hint=3Drefresh_token
>>>>> >
>&= gt;>>> > =C2=A0 The following is a non-normative example reques= t in which the
>>>>> client uses
>>>>> = > =C2=A0 its access token to revoke the same access token:
>>&g= t;>> >
>>>>> > =C2=A0 =C2=A0 POST /revoke HTT= P/1.1
>>>>> > =C2=A0 =C2=A0 Host: server.example.com
>>>>> > =C2=A0 =C2=A0 Co= ntent-Type: application/x-www-form-urlencoded
>>>>> > = =C2=A0 =C2=A0 Authorization: Bearer czZCaGRSa3F0MzpnWDFmQmF0M2JW
>>= ;>>> >
>>>>> > =C2=A0 =C2=A0 token=3DczZCa= GRSa3F0MzpnWDFmQmF0M2JW&token_type_hint=3Daccess_token
>>>&= gt;> >
>>>>> > =C2=A0 The authorization server M= UST validate the access token used by
>>>>> the
>&g= t;>>> > =C2=A0 client to authorize its call to the revocation e= ndpoint, including
>>>>> > =C2=A0 ensuring that it is = not expired or revoked.
>>>>> > =C2=A0 Additionally, t= he authorization server MUST also validate whether
>>>>> = the
>>>>> > =C2=A0 access token used for authorization= is part of the same grant =C2=A0as
>>>>> the
>>= >>> > =C2=A0 token being revoked. If validation fails, the requ= est is =C2=A0refused
>>>>> and
>>>>> &g= t; =C2=A0 the client is informed of the error by the authorization server.<= br>>>>>> > =C2=A0 In the case of a bearer token, the auth= orization server SHOULD
>>>>> respond
>>>>= > > =C2=A0 with an HTTP 401 code as described in OAuth 2.0 Bearer Tok= en Usage
>>>>> > =C2=A0 [RFC6750], Section 3.
>&= gt;>>> > =C2=A0 Errors based on other types of tokens are beyon= d the scope of this
>>>>> > =C2=A0 specification.
&= gt;>>>> >
>>>>> >
>>>>&g= t; > Notes
>>>>> > -----
>>>>> &g= t; It appears as though the authors of RFC7009 have failed to consider
&= gt;>>>> that requests to revoke are likely to come from non-con= fidential clients
>>>>> and such, would lack authenticati= on credentials. Regardless of the type of
>>>>> client ho= wever, authentication should not be required. The OAuth 2.0
>>>= >> specification (RFC6749) does not specify verifying that the access= token
>>>>> belongs to the client accessing protected re= sources, of which revocation is
>>>>> one. It is the role= of the access token alone to signify authorization
>>>>>= required to make requests to protected resources. If this is an issue for<= br>>>>>> revocation, then it is an issue for all protected r= esources and counter
>>>>> measures may be proposed in a = separate RFC rather than broadening the scope
>>>>> of th= is particular RFC. As per the original text itself, "This
>>&= gt;>> specification in general does not intend to provide countermeas= ures against
>>>>> token theft and abuse." Additiona= lly, "If an attacker is able to
>>>>> successfully g= uess a public client's client_id and one of their tok
>>>&g= t;> > ens, or a private client's credentials and one of their tok= ens, they
>>>>> could do much worse damage by using the t= oken elsewhere than by revoking
>>>>> it.=C2=A0 If they c= hose to revoke the token, the legitimate client will lose its
>>&g= t;>> authorization grant and will need to prompt the user again.=C2= =A0 No further
>>>>> damage is done and the guessed token= is now worthless."
>>>>> > Note that the client_= id is not meant to be private information to
>>>>> begin = with, so relying on an attacker "guessing" it should not be seen = as a
>>>>> security countermeasure. This section of RFC70= 09 will be referenced in a
>>>>> subsequent errata.
&g= t;>>>> >
>>>>> > Instructions:
>&= gt;>>> > -------------
>>>>> > This erratu= m is currently posted as "Reported". If necessary, please
>= >>>> > use "Reply All" to discuss whether it shoul= d be verified or
>>>>> > rejected. When a decision is = reached, the verifying party
>>>>> > can log in to cha= nge the status and edit the report, if necessary.
>>>>> &= gt;
>>>>> > --------------------------------------
= >>>>> > RFC7009 (draft-ietf-oauth-revocation-11)
>&= gt;>>> > --------------------------------------
>>>= >> > Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : OAut= h 2.0 Token Revocation
>>>>> > Publication Date =C2=A0= =C2=A0: August 2013
>>>>> > Author(s) =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : T. Lodderstedt, Ed., S. Dronia, M. Scurtescu
>= >>>> > Category =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: P= ROPOSED STANDARD
>>>>> > 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: Sec= urity
>>>>> > Stream =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0: IETF
>>>>> > Verifying Party =C2=A0= =C2=A0 : IESG
>>>>> >
>>>>> > __= _____________________________________________
>>>>> > = OAuth mailing list
>>>>> > OAuth@ietf.org
>>>>> > https://www.ietf.org/mailman/lis= tinfo/oauth
>>>>>
>>>>> ___________= ____________________________________
>>>>> OAuth mailing = list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>&= gt;>>>
>>>> _______________________________________= ________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>= >> https://www.ietf.org/= mailman/listinfo/oauth
>>>>
>>> ____________= ___________________________________
>> OAuth mailing list
>&= gt; OAuth@ietf.org<= br>>> https://www.ietf.o= rg/mailman/listinfo/oauth
>>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dht= tps://www.ietf.org/mailman/listinfo/oauth&source=3Dgmail-imap&ust= =3D1630975362000000&usg=3DAOvVaw0SBRIZ3JVu9V2FyhP0VRFL

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000ed211305cb037011-- From nobody Thu Sep 2 16:20:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D923A1769 for ; Thu, 2 Sep 2021 16:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=backbase.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmz2fpWr86SV for ; Thu, 2 Sep 2021 16:20:29 -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 1A0843A1765 for ; Thu, 2 Sep 2021 16:20:29 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id f18so7831440lfk.12 for ; Thu, 02 Sep 2021 16:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=aorauIwsMazEYmw7IahB//ycOBHlAGqLIS80wW7bWWY=; b=GrLWYL5Tetw6Y9g1uUSnI7oWIaIwbIY6zoPxe4hZGUu+BZ/RbxBRA4lkZRXJKzmNXT T7VMJqKPQhvVMTZZ7W4h5+VmcOOVLN9RfhLHUokZ9cTYkZa4tPoyV2nJZh8T7gPKM209 ajsAOA8CEhQjGyVQeHX+cmr/bx9blldLDodfdqV6kYnCBlf0H4RDobYWjPWyB/sVeJWP 01Uo1LSEHitfMtIuKY/TS0KuQ69Ldd4/p3Tahgfkmb1RsP/S91JXp+jBBBCpxk3W27wQ 5VXpQ/YlSX9Z/KrAbCdZteF8SQFfLOkda98X+jgLKm+NJEE26I7FAFY/0ClPy4G3o8at LHjg== 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=aorauIwsMazEYmw7IahB//ycOBHlAGqLIS80wW7bWWY=; b=qQeyNhSayu7F8AU2F4b0jMMx5ZX5qQxO5IdGrQNhxK0ZEKI3iDp1YEAfY5Yvc5W5DZ A7NiFwX23U5q9sfqmXZnPFJiMTSPjPO5lT69OwqehUG3zVnnFZw4rkN6buA2cU8uYzt5 Ld1F1FVFhjTStzdqSl98t6VFXxf0sZlGhhSASZplSBpLTGjFS0tv0UzWph2g1TQZQUdU kulHHSYtcrFn2u/RS1+4pSBDs7h3rWuv471GXvMT+esdNU0t8DgDh04PBA45jTI4cZKh CNI8V49juKlabkT0mYs8ZDwIm2gQCxBgY6UnAomiRUUCmTI7HUTdoDTlIgfGlublgT5T 1rQA== X-Gm-Message-State: AOAM530xZo99GhGabUDP17YZxpn3l8lmdnmAO8aPUlEjJ1WipOC+Dkcg QIVtRq9XbvyS93d7RAdCh0r6zXzuHSSWNZsxDQgYNLbso9upfg== X-Google-Smtp-Source: ABdhPJxGJht8ZdzF5cXXddqwk1ThqoNtDYjgXNEUoxRfEuGjc/ngqMY41rOEtDxL2xJk3JQjSyAzEhqkVp5KIYwy5Ps= X-Received: by 2002:ac2:5c4b:: with SMTP id s11mr414191lfp.368.1630624825229; Thu, 02 Sep 2021 16:20:25 -0700 (PDT) MIME-Version: 1.0 From: Dmitry Telegin Date: Fri, 3 Sep 2021 02:20:14 +0300 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000786ae605cb0b6d17" Archived-At: Subject: [OAUTH-WG] DPoP 03 - access_token as a POST parameter + Bearer/DPoP multi-scheme protected 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: Thu, 02 Sep 2021 23:20:35 -0000 --000000000000786ae605cb0b6d17 Content-Type: text/plain; charset="UTF-8" Hi, The Bearer Token Usage RFC allows for an access token to be passed as a body form-encoded parameter. With DPoP, this leads to ambiguity if a protected resource supports DPoP and Bearer schemes simultaneously, as per DPoP Section 7.2. The ambiguity arises from the inability to derive the authentication scheme used with the token, as opposed to "Authorization: XXX" header use. In its turn, the scheme would be needed for the protected resource to form the correct "WWW-Authenticate" challenge in the case of invalid token. (For a protected resource supporting Bearer and DPoP in parallel, the challenge would include both schemes.) Example challenge for the Bearer scheme: 401 Unauthorized WWW-Authenticate: Bearer realm="foo", error="invalid_token", DPoP realm="foo", algs="ES256" Example challenge for the DPoP scheme: 401 Unauthorized WWW-Authenticate: Bearer realm="foo", DPoP realm="foo", error="invalid_token", algs="ES256" (In a nutshell, we need to know which scheme in the challenge should be marked as failed, and thus include the "error=..." attribute.) Additionally, the knowledge of the scheme would be needed to properly prevent the downgraded usage of DPoP-bound tokens, as per DPoP Section 7.2. This might seem an insignificant edge case, but there is an important instance of such a protected resource, namely OIDC UserInfo endpoint. As per OpenID Connect Core, 5.3 UserInfo Endpoint : The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns > Claims about the authenticated End-User. > The UserInfo Endpoint MUST support the use of the HTTP GET and HTTP POST > methods defined in RFC 2616 [RFC2616]. > The UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token > Usage [RFC6750]. > The problem is that UserInfo is not bound to any client, and DPoP support would be normally enabled/disabled on a per client basis (rather than per-realm or per-server). Therefore, UserInfo won't be able to make a decision upon the default authentication scheme until it parses the token and resolves a client that it was issued for; it might not be able to do this at all in the case of invalid token. Hence, UserInfo must support (and advertise via WWW-Authenticate) both Bearer and DPoP schemes simultaneously, and to deduce which one has been used with the POST request containing access_token as a form-encoded param. I see the following possible approaches: - require that hybrid Bearer/DPoP protected resources honor a variant of the POST parameter, like e.g. "access_token+dpop=...", or - restrict the use of access_token POST param and require that "Authorization: XXX" header be always used with DPoP. What do you think? Dmitry --000000000000786ae605cb0b6d17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The Bearer Token Usage RFC allows for an access = token to be passed as a body form-encoded parameter. With DPoP, this leads = to ambiguity if a protected resource supports DPoP and Bearer schemes simul= taneously, as per DPoP Section 7.2.

The ambiguity arises from the in= ability to derive the authentication scheme used with the token, as opposed= to "Authorization: XXX" header use. In its turn, the scheme woul= d be needed for the protected resource to form the correct "WWW-Authen= ticate" challenge in the case of invalid token. (For a protected resou= rce supporting Bearer and DPoP in parallel, the challenge would include bot= h schemes.)

Example challenge for the Bearer scheme:

401 Unau= thorized
=C2=A0=C2=A0=C2=A0 WWW-Authenticate: Bearer realm=3D"foo&q= uot;, error=3D"invalid_token", DPoP realm=3D"foo", algs= =3D"ES256"

Example challenge for the DPoP scheme:

4= 01 Unauthorized
=C2=A0=C2=A0=C2=A0 WWW-Authenticate: Bearer realm=3D&quo= t;foo", DPoP realm=3D"foo", error=3D"invalid_token"= ;, algs=3D"ES256"

(In a nutshell, we need to know which sc= heme in the challenge should be marked as failed, and thus include the &quo= t;error=3D..." attribute.)

Additionally, the knowledge of the s= cheme would be needed to properly prevent the downgraded usage of DPoP-boun= d tokens, as per DPoP Section 7.2.

This might seem an insignificant = edge case, but there is an important instance of such a protected resource,= namely OIDC UserInfo endpoint. As per OpenID Connect Core, 5.3 UserInfo En= dpoint:

The Us= erInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims abou= t the authenticated End-User.
The UserInfo Endpoint MUST support the use= of the HTTP GET and HTTP POST methods defined in RFC 2616 [RFC2616].
Th= e UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token Usa= ge [RFC6750].

The problem is that UserInfo is not bound= to any client, and DPoP support would be normally enabled/disabled on a pe= r client basis (rather than per-realm or per-server). Therefore, UserInfo w= on't be able to make a decision upon the default authentication scheme = until it parses the token and resolves a client that it was issued for; it = might not be able to do this at all in the case of invalid token. Hence, Us= erInfo must support (and advertise via WWW-Authenticate) both Bearer and DP= oP schemes simultaneously, and to deduce which one has been used with the P= OST request containing access_token as a form-encoded param.

I see t= he following possible approaches:
- require that hybrid Bearer/DPoP prot= ected resources honor a variant of the POST parameter, like e.g. "acce= ss_token+dpop=3D...", or
- restrict the use of access_token POST pa= ram and require that "Authorization: XXX" header be always used w= ith DPoP.

What do you think?
Dmitry
--000000000000786ae605cb0b6d17-- From nobody Thu Sep 2 22:58:48 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15F73A07F2 for ; Thu, 2 Sep 2021 22:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wqiRKfcWy0gh for ; Thu, 2 Sep 2021 22:58:38 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915993A07F0 for ; Thu, 2 Sep 2021 22:58:38 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id r4so8185484ybp.4 for ; Thu, 02 Sep 2021 22:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+OLLoBHzSCQAkrnjFcB7QOzGjfODqaLidwQhs2Q8D8w=; b=IOnQofTwLozqpERcl1RZX1laplkrhkSD8wmZeTUVsiyfrjyT66htoMKpdapC2RRsQ4 RjzMugjgFNa1vgkmKI3Y/FzI8kMth6lMV/tudR1h1U3EmbKbe3F3mCynYfz6lkin2swj 769zix2DowcE9z3P8fxgnxgC/1cyFBkpqgJlLxVgTE09W0hnDsd6WRAfcsT9W3E3X416 9mglMzXckCHlw7+7gEM14dnUFV3OB9qC1prmMnwfnYkJObRrGJka5+AIglizRnZAkL2K 6VyQccXOKuamz9y48sneiIfRQFvAd4jL/dHSEJaEEFpvvozVrr3nrqfjqPP1JgY3jmsC NtRw== 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=+OLLoBHzSCQAkrnjFcB7QOzGjfODqaLidwQhs2Q8D8w=; b=G8CljOp8QHcMK5DiSPwSoX8/r3YqaY/ri9rThjlHdHyvc6RH6IAkS21KoDem1BhhCV g8HllB2D6Wou/I3xBADzflPAgRWECxx3b7k7k4EmX8AtTkTYwhIGavtUIb3p583o0nYD mD/0G9LeyhSHKSVvUH0D4ZZtWHr+S0psucDyDw4XilABIoD/3UVyfSIQ3OPaePJbYY7w Qd78sbSyheoNbI2p3tGU42odRebjWIi9xImZKLz7kkl98XZ0Cn5WY/V6CotC2yaqc64h xU9WEK7cFOWQvtGx9V3+aRTcj5GR5Ub4QGVLPaz06ZAuiMXfjYJaZUMfRQ4aTeLPlI3H B1lQ== X-Gm-Message-State: AOAM532Db01oQD+DUMjvzqbZG+KE6DE9hzIwJvE4dCs5C3X1S+3u6EUE gUbHqdxicQt+9WO7y2pLfIw0n4JdUWqzqb2fquRgKzc= X-Google-Smtp-Source: ABdhPJw1EYvzXtNy6UAcholooRLMVRdzQ+pd77JPydQdMBvKuMEtWMuWwZryuxe1LTOSpr0kco4FNjlapu5uaGw4NCk= X-Received: by 2002:a25:5686:: with SMTP id k128mr2820592ybb.127.1630648716005; Thu, 02 Sep 2021 22:58:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Fri, 3 Sep 2021 07:58:00 +0200 Message-ID: To: Dmitry Telegin Cc: oauth Content-Type: multipart/alternative; boundary="00000000000078947405cb10fd33" Archived-At: Subject: Re: [OAUTH-WG] DPoP 03 - access_token as a POST parameter + Bearer/DPoP multi-scheme protected 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: Fri, 03 Sep 2021 05:58:45 -0000 --00000000000078947405cb10fd33 Content-Type: text/plain; charset="UTF-8" Hello Dmitry, I believe it is the case that DPoP only defines Authorization Header use. Sending a DPoP type access token in a POST body parameter or query string is, unlike with Bearer, not defined. Best, *Filip* On Fri, 3 Sept 2021 at 01:21, Dmitry Telegin wrote: > Hi, > > The Bearer Token Usage RFC allows > for an access > token to be passed as a body form-encoded parameter. With DPoP, this leads > to ambiguity if a protected resource supports DPoP and Bearer schemes > simultaneously, as per DPoP Section 7.2. > > The ambiguity arises from the inability to derive the authentication > scheme used with the token, as opposed to "Authorization: XXX" header use. > In its turn, the scheme would be needed for the protected resource to form > the correct "WWW-Authenticate" challenge in the case of invalid token. (For > a protected resource supporting Bearer and DPoP in parallel, the challenge > would include both schemes.) > > Example challenge for the Bearer scheme: > > 401 Unauthorized > WWW-Authenticate: Bearer realm="foo", error="invalid_token", DPoP > realm="foo", algs="ES256" > > Example challenge for the DPoP scheme: > > 401 Unauthorized > WWW-Authenticate: Bearer realm="foo", DPoP realm="foo", > error="invalid_token", algs="ES256" > > (In a nutshell, we need to know which scheme in the challenge should be > marked as failed, and thus include the "error=..." attribute.) > > Additionally, the knowledge of the scheme would be needed to properly > prevent the downgraded usage of DPoP-bound tokens, as per DPoP Section 7.2. > > This might seem an insignificant edge case, but there is an important > instance of such a protected resource, namely OIDC UserInfo endpoint. As > per OpenID Connect Core, 5.3 UserInfo Endpoint > : > > The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns >> Claims about the authenticated End-User. >> The UserInfo Endpoint MUST support the use of the HTTP GET and HTTP POST >> methods defined in RFC 2616 [RFC2616]. >> The UserInfo Endpoint MUST accept Access Tokens as OAuth 2.0 Bearer Token >> Usage [RFC6750]. >> > > The problem is that UserInfo is not bound to any client, and DPoP support > would be normally enabled/disabled on a per client basis (rather than > per-realm or per-server). Therefore, UserInfo won't be able to make a > decision upon the default authentication scheme until it parses the token > and resolves a client that it was issued for; it might not be able to do > this at all in the case of invalid token. Hence, UserInfo must support (and > advertise via WWW-Authenticate) both Bearer and DPoP schemes > simultaneously, and to deduce which one has been used with the POST request > containing access_token as a form-encoded param. > > I see the following possible approaches: > - require that hybrid Bearer/DPoP protected resources honor a variant of > the POST parameter, like e.g. "access_token+dpop=...", or > - restrict the use of access_token POST param and require that > "Authorization: XXX" header be always used with DPoP. > > What do you think? > Dmitry > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000078947405cb10fd33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Dmitry,

I believe it is the case = that DPoP only defines Authorization Header use. Sending a DPoP type access= token in a POST body parameter or query string is, unlike with Bearer, not= defined.

Best,
Filip


On Fri, 3 Sept 2021 at 01:21, Dmitry Telegin <dmitryt=3D= 40backbase.com@dmarc.ietf.= org> wrote:
Hi,

The Bearer Token Usage RFC allo= ws for an access token to be passed as a body form-encoded parameter. W= ith DPoP, this leads to ambiguity if a protected resource supports DPoP and= Bearer schemes simultaneously, as per DPoP Section 7.2.

The ambigui= ty arises from the inability to derive the authentication scheme used with = the token, as opposed to "Authorization: XXX" header use. In its = turn, the scheme would be needed for the protected resource to form the cor= rect "WWW-Authenticate" challenge in the case of invalid token. (= For a protected resource supporting Bearer and DPoP in parallel, the challe= nge would include both schemes.)

Example challenge for the Bearer sc= heme:

401 Unauthorized
=C2=A0=C2=A0=C2=A0 WWW-Authenticate: Beare= r realm=3D"foo", error=3D"invalid_token", DPoP realm=3D= "foo", algs=3D"ES256"

Example challenge for the = DPoP scheme:

401 Unauthorized
=C2=A0=C2=A0=C2=A0 WWW-Authenticate= : Bearer realm=3D"foo", DPoP realm=3D"foo", error=3D&qu= ot;invalid_token", algs=3D"ES256"

(In a nutshell, we = need to know which scheme in the challenge should be marked as failed, and = thus include the "error=3D..." attribute.)

Additionally, t= he knowledge of the scheme would be needed to properly prevent the downgrad= ed usage of DPoP-bound tokens, as per DPoP Section 7.2.

This might s= eem an insignificant edge case, but there is an important instance of such = a protected resource, namely OIDC UserInfo endpoint. As per OpenID Connect Core, 5.3 UserInfo Endpoint:

The UserInfo Endpoint is an OAuth 2.0 Prot= ected Resource that returns Claims about the authenticated End-User.
The= UserInfo Endpoint MUST support the use of the HTTP GET and HTTP POST metho= ds defined in RFC 2616 [RFC2616].
The UserInfo Endpoint MUST accept Acce= ss Tokens as OAuth 2.0 Bearer Token Usage [RFC6750].

Th= e problem is that UserInfo is not bound to any client, and DPoP support wou= ld be normally enabled/disabled on a per client basis (rather than per-real= m or per-server). Therefore, UserInfo won't be able to make a decision = upon the default authentication scheme until it parses the token and resolv= es a client that it was issued for; it might not be able to do this at all = in the case of invalid token. Hence, UserInfo must support (and advertise v= ia WWW-Authenticate) both Bearer and DPoP schemes simultaneously, and to de= duce which one has been used with the POST request containing access_token = as a form-encoded param.

I see the following possible approaches:- require that hybrid Bearer/DPoP protected resources honor a variant of t= he POST parameter, like e.g. "access_token+dpop=3D...", or
- r= estrict the use of access_token POST param and require that "Authoriza= tion: XXX" header be always used with DPoP.

What do you think?<= br>Dmitry
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000078947405cb10fd33-- From nobody Fri Sep 3 07:43:02 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076113A20C8 for ; Fri, 3 Sep 2021 07:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYh95OYzBsTk for ; Fri, 3 Sep 2021 07:42:54 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A11BE3A20C6 for ; Fri, 3 Sep 2021 07:42:54 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id a93so10534383ybi.1 for ; Fri, 03 Sep 2021 07:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=oZpkqfWUxGON+2VoRY/NK9Oh47BgeDklyVf/2FH+jz0=; b=zmR44jebVzr8loCb5Zs4l0iPWLDYlnYqmK2tIxvlu8ZFG3I5gdTkAKBi5+x9NCcW4K 5k1uNv7RqeLdXn/NdhwXQmYmPlNybcpSK/iSPPbalDJlMLTgkWXpSeyDK3ULT9n994FH p4JmEctiij18D8uvkyP+rcCWZIpI31NRqrE5mhDtewmxRFd5IKfBx+002xR8KvP7RbuK w/saxGKaxcEwVsYWJ2mXU9eD8Tlvrn4Dl8wHwUZb+jmqY4gyUidpJ4CSj7Ic/LdhYbiO LWyA2kz9S0JPoM+5pBkLTvxT4BVhi31hKuNr181xbQl17MdC+9hKPyY5zPp6ij18sg06 +c5Q== 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=oZpkqfWUxGON+2VoRY/NK9Oh47BgeDklyVf/2FH+jz0=; b=WOB7AyMo/M0253y8P/Iylno7fAujSqL6B/RptxEZjTTwxv6uyF8O9Dw/ppdf/6MJN7 QpS4pvBETKbzMBs9RK9iKC4T/VH3amxyRK9eL1yhHR30Hc7/sM1w/DMI9GGgsE5PY9E1 AoJQ1u3q7hyxmJV6O/TpBYulu0f7E4lBDH1U845c3waAhyChSSr7s8d8snA3hFmmut6T 8+5IbG8GuaZDxn5fJKbeRE7qj8mqVaLDf/DYBV3RnSZKqT8bN5HaJWMBZZFWt4Ry2RA+ Zo4n0LDDwunmspbp/dWt9bJ4D/HItHnlvvk3NiscnC84HjQeJ1LsxuiFs3BVP32t6pc6 ZOoA== X-Gm-Message-State: AOAM533ubfWpYdAXQRgTF3Ok9FL6oFcJm3IvcqcSPIShRlvcuWv7u4/v z5vKzFgDas8teEXjQ1cM7bie6DQVgk8jovajnNpmeQs7Iq3dSbjg X-Google-Smtp-Source: ABdhPJzvmqpssbWfwlNywvAnJwDLBLl+EDljxXcOasnJDIUUG5xmkzxle2BV9Y0MMjcMClFFuuM5yM2Q0eXufOB7AxA= X-Received: by 2002:a05:6902:1004:: with SMTP id w4mr5569916ybt.11.1630680172084; Fri, 03 Sep 2021 07:42:52 -0700 (PDT) MIME-Version: 1.0 From: Jacob Ideskog Date: Fri, 3 Sep 2021 16:42:41 +0200 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000665f4905cb185024" Archived-At: Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 14:43:00 -0000 --000000000000665f4905cb185024 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that describes the token response. The authorization_details values could be sensitive in their nature. The example in section 7.1 highlights this nicely. The accounts array is empty when the client requests it, but is enriched by the AS and returned to the client in the token response. This means that the AS may leak potentially sensitive information to the client in a new place. Before this was only possible in the ID Token or UserInfo or if the AS returned a JWT as an access token which the client popped open (even though it shouldn't). I understand that the spec considers this an option for the AS to enrich or not. I think the enrichment is good and necessary, but with the side-effect of it ending up in the token response it becomes an issue. Is the token response a mirror of the authorization_details claim in the corresponding access token, or can it be a masked version? Perhaps the security considerations section should be updated with a statement with regards to the fact that the client may see claim data only intended for the RS? Regards Jacob Ideskog --=20 Jacob Ideskog CTO Curity AB ------------------------------------------------------------------- Sankt G=C3=B6ransgatan 66, Stockholm, Sweden M: +46 70-2233664 j acob@curity.io curity.io ------------------------------------------------------------------- --000000000000665f4905cb185024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have a question ab= out section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that describes the token= response.

The authorization_details values could = be sensitive in their nature. The example in section 7.1 highlights this ni= cely. The accounts array is empty when the client requests it, but is enric= hed by the AS and returned to the client in the token response.
<= br>
This means that the AS may leak potentially sensitive informa= tion to the client in a new place. Before this was only possible in the ID = Token or UserInfo or if the AS returned a JWT as an access token which the = client popped open (even though it shouldn't).

I understand that the spec considers this an option for the AS to enrich o= r not. I think the enrichment is good and necessary, but with the side-effe= ct of it ending up in the token response it becomes an issue.
Is the token response a mirror of the authorization_details cla= im in the corresponding access token, or can it be a masked version?
<= div>
Perhaps the security considerations section should be up= dated with a statement with regards to the fact that the client may see cla= im data only intended for the RS?

Regards
Jacob Ideskog



--
<= div dir=3D"ltr">
Jacob Ideskog
CTO
Curi= ty AB
---------------------= -----------------------------= -----------------
= Sankt G=C3=B6ransgatan 66, Stockholm, Sweden
M:=C2=A0+46 70-2233664
jacob@curity.io
-------------------------------------------------------------------
--000000000000665f4905cb185024-- From nobody Fri Sep 3 18:12:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457DF3A102B for ; Fri, 3 Sep 2021 18:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88ZyHIJZgbkx for ; Fri, 3 Sep 2021 18:12:27 -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 A800D3A1027 for ; Fri, 3 Sep 2021 18:12:27 -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 1841BwgB012807; Fri, 3 Sep 2021 21:12:24 -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.1497.23; Fri, 3 Sep 2021 21:11:52 -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.1497.23; Fri, 3 Sep 2021 21:10:47 -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.1497.023; Fri, 3 Sep 2021 21:10:47 -0400 From: Justin Richer To: Jacob Ideskog , oauth Thread-Topic: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05 Thread-Index: AQHXoNHlxW4wr2+flkygKWnVCmwDKKuTEOX/ Date: Sat, 4 Sep 2021 01:10:47 +0000 Message-ID: <250c6a12d1ab42a4869a0a9689ad1625@oc11expo18.exchange.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-transport-fromentityheader: Hosted x-originating-ip: [172.58.172.108] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 01:12:33 -0000 This is a fair point... The privacy and security considerations talk about = this a bit as I recall, but likely need to in more depth and specificity. T= his is an intentional message channel to the client from the AS, but if the= AS is blindly sending all information it might be saying more than it mean= s to say to an entity that doesn't need that detail to function. Scopes hav= e similar issues, but this structure adds more opportunities for mistakes j= ust due to the possible increased complexity.=20 -Justin ________________________________________ From: OAuth [oauth-bounces@ietf.org] on behalf of Jacob Ideskog [jacob.ides= kog@curity.io] Sent: Friday, September 3, 2021 10:42 AM To: oauth Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ie= tf-oauth-rar-05 Hi all, I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 that= describes the token response. The authorization_details values could be sensitive in their nature. The ex= ample in section 7.1 highlights this nicely. The accounts array is empty wh= en the client requests it, but is enriched by the AS and returned to the cl= ient in the token response. This means that the AS may leak potentially sensitive information to the cl= ient in a new place. Before this was only possible in the ID Token or UserI= nfo or if the AS returned a JWT as an access token which the client popped = open (even though it shouldn't). I understand that the spec considers this an option for the AS to enrich or= not. I think the enrichment is good and necessary, but with the side-effec= t of it ending up in the token response it becomes an issue. Is the token response a mirror of the authorization_details claim in the co= rresponding access token, or can it be a masked version? Perhaps the security considerations section should be updated with a statem= ent with regards to the fact that the client may see claim data only intend= ed for the RS? Regards Jacob Ideskog -- Jacob Ideskog CTO Curity AB ------------------------------------------------------------------- Sankt G=F6ransgatan 66, Stockholm, Sweden M: +46 70-2233664 jacob@curity.io curity.io ------------------------------------------------------------------- From nobody Sat Sep 4 02:41:20 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDAF3A0955 for ; Sat, 4 Sep 2021 02:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZYRH-69QbFY for ; Sat, 4 Sep 2021 02:41:13 -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 114C03A0953 for ; Sat, 4 Sep 2021 02:41:12 -0700 (PDT) Received: by mail-wr1-x433.google.com with SMTP id n5so2057800wro.12 for ; Sat, 04 Sep 2021 02:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=MOZ/U4vJPy8yJo0b6dDyKcxPq9f/bgXd5PBg1/X9bY0=; b=dxHZFixNltlshtRdhfHqxjWzQMBUJ8WF0SuDNTKXngZLqJQi8xj/H2UppMQuZufQBi FYsChwh+cqTZSk2Op3EuaEuE9hVmunA+jSAB72nNotzXWfGxaXLMFFikSFAKyL1sAZb+ J00RgGs5MV2U1dDfSRjBu0q8xExdVygVwCLmFVi94hrykNtitkieTPGBQrwd9+icsh0k hU7BW6YCozrkwSDMXUcJOabsnfuTT3Ix3Sg5K/34gA8hb5IHn7efiU0InDQPtTMbMFxT DY5yPsmFwVGRd6bI5lEBd8JziATMPDTRBiHLgyoUJHVHqNh0hBM9yfve2erV2R3Y8b2s yOyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=MOZ/U4vJPy8yJo0b6dDyKcxPq9f/bgXd5PBg1/X9bY0=; b=f9PyLO6rgFlsDjT72OYs566Y0/mH/652gyDUSdmPvYYjKbsPWlqMRYZho/P/yePuMh /WkxHdTf0G4jdgzmxlk/FD8G9KST1zLk4NlrGOwipchXzaz7/iQHo4a/Sx9lfFK3PePi dTIYpnVGkEcUTKuK4q4RLdwiqQrTfePoyRZJQKf3+TYFlNAjRCjuMC6kqVVZsJ7lkOVu TJTB59bXMViyzj6gqxDsYno+Mx7u6KuhPpkA0ivwHxd2nobU4H1YGbkjYk9JhMwwrF4p P+uwG/sJ9XEfCl+VqN9pkESXmlVgKODtjNTVTuFjAL9+NelNIrgcW8zao1Abkh0DILgV NMGg== X-Gm-Message-State: AOAM533Qp4bZHVmM0PU09qXKA/hf93vDdrY6WSY7gS7eor/lMwFuYTbm 6yoVEOm27C8Rkkp4hIXogiWFsSgSjdl4tA== X-Google-Smtp-Source: ABdhPJziNDrTRw/Ve6wvZbg42LYxesvnuggqo9aVLPG1gYC2afg+f0gd9B1V4oTIHg+FsJEQxhMbeg== X-Received: by 2002:adf:eb4c:: with SMTP id u12mr3232885wrn.111.1630748469119; Sat, 04 Sep 2021 02:41:09 -0700 (PDT) Received: from smtpclient.apple (p4fc0815a.dip0.t-ipconnect.de. [79.192.129.90]) by smtp.gmail.com with ESMTPSA id t14sm1614913wmi.12.2021.09.04.02.41.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Sep 2021 02:41:08 -0700 (PDT) Content-Type: multipart/signed; boundary=Apple-Mail-2CEECCB1-59C4-48C9-A46F-3862996FAB7C; protocol="application/pkcs7-signature"; micalg=sha-256 Content-Transfer-Encoding: 7bit From: Torsten Lodderstedt Mime-Version: 1.0 (1.0) Date: Sat, 4 Sep 2021 11:41:06 +0200 Message-Id: <0C5C7579-2979-4B64-8163-BA254B07CFC1@lodderstedt.net> References: <250c6a12d1ab42a4869a0a9689ad1625@oc11expo18.exchange.mit.edu> Cc: oauth , Justin Richer In-Reply-To: <250c6a12d1ab42a4869a0a9689ad1625@oc11expo18.exchange.mit.edu> To: Jacob Ideskog X-Mailer: iPad Mail (18G82) Archived-At: Subject: Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 09:41:19 -0000 --Apple-Mail-2CEECCB1-59C4-48C9-A46F-3862996FAB7C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The AS intentionally shares the list of accounts in the mentioned example wi= th the client. The assumption is the client asks for access to some accounts= and the user decides which accounts to grant the client access to. This mea= ns the AS is authorized by the user to share this data. The privacy considerations section already has text about sharing data with r= esource servers. I suggest to add some text re data sharing with clients. Would that work for you? > Am 04.09.2021 um 03:12 schrieb Justin Richer : >=20 > =EF=BB=BFThis is a fair point... The privacy and security considerations t= alk about this a bit as I recall, but likely need to in more depth and speci= ficity. This is an intentional message channel to the client from the AS, bu= t if the AS is blindly sending all information it might be saying more than i= t means to say to an entity that doesn't need that detail to function. Scope= s have similar issues, but this structure adds more opportunities for mistak= es just due to the possible increased complexity.=20 >=20 > -Justin > ________________________________________ > From: OAuth [oauth-bounces@ietf.org] on behalf of Jacob Ideskog [jacob.ide= skog@curity.io] > Sent: Friday, September 3, 2021 10:42 AM > To: oauth > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-i= etf-oauth-rar-05 >=20 > Hi all, >=20 > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 tha= t describes the token response. >=20 > The authorization_details values could be sensitive in their nature. The e= xample in section 7.1 highlights this nicely. The accounts array is empty wh= en the client requests it, but is enriched by the AS and returned to the cli= ent in the token response. >=20 > This means that the AS may leak potentially sensitive information to the c= lient in a new place. Before this was only possible in the ID Token or UserI= nfo or if the AS returned a JWT as an access token which the client popped o= pen (even though it shouldn't). >=20 > I understand that the spec considers this an option for the AS to enrich o= r not. I think the enrichment is good and necessary, but with the side-effec= t of it ending up in the token response it becomes an issue. >=20 > Is the token response a mirror of the authorization_details claim in the c= orresponding access token, or can it be a masked version? >=20 > Perhaps the security considerations section should be updated with a state= ment with regards to the fact that the client may see claim data only intend= ed for the RS? >=20 > Regards > Jacob Ideskog >=20 >=20 >=20 > -- > Jacob Ideskog > CTO > Curity AB > ------------------------------------------------------------------- > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden > M: +46 70-2233664 > jacob@curity.io > curity.io > ------------------------------------------------------------------- >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1631322760000000&usg=3DAOvVaw2Fa1GyOiE6a7mRCghwMI= 5J --Apple-Mail-2CEECCB1-59C4-48C9-A46F-3862996FAB7C Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBPgw ggT0MIID3KADAgECAhBpfEIkHQiWmzF6zDsgdF+DMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEjMCEGA1UE CgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1 dGhlbnRpY2F0aW9uIENBIEcyMB4XDTIwMDIyMzE3MjEzOVoXDTIxMDIyMzE3MjEzOVowIjEgMB4G A1UEAwwXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrIaCISpAU98m6ZkDyUR3My5imAF4TKQk8eqo+oQ06PTWT/3yJXujVCjjOqOl8p11v/RoN Gf8zqYbBsqGBuJx2NyxFmAnmCjcbnxihQdcmuxLm6izvxr2MawOovDheMXnfmGy/Ns5Fs6bd+M5F jCNhP+Gljvgm/SFq1skvs7YUX2FxZmh+xPMm3FZ/a6Lyhkrd3JHzEqv8VWY69Aehezg39OuPJEpb IdjK/eBcmaIG0qn5RQdXLByJYfXhepyVAZPJT5rAgaIQL/IjSIVInxf3FxOv+ELMAErclws6mKzy zkY2JiItPEpKWzAWGCxCX2o0JjVj1f7xgaunLfJ+Ec0lAgMBAAGjggG4MIIBtDAMBgNVHRMBAf8E AjAAMB8GA1UdIwQYMBaAFGvyjZ5owSUEH1E0V/YWXJTqTWkaMH4GCCsGAQUFBwEBBHIwcDA7Bggr BgEFBQcwAoYvaHR0cDovL2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzIw MQYIKwYBBQUHMAGGJWh0dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzIwIgYDVR0R BBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggr BgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxp cy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMi9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSuRfshihlGSEJ7 2UeyOZRJ1YYyMDAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggEBAH/3ECMSOoOLiwCe GsBj/WWnUhXvZyHmz3LW0DVdH3s30b2HWpomEVNDN3cWt4QSRhISqV0xyyChL6THhDY+Um2mo+z/ L5fxHd3MjhzvYKwUtLUJdWRgymlUBO9zNKi/IMVYv3O+mpOHuQrgtMaV9luDPRYPZrhF9y/InTZE tb+FOrF9ykIRlYgMzqSKjuqFmmYO4d6GkbgfGKFZsAjkySjM9BUBLb70MdysOTxZ/HtZguIKfZ4q CveZ9ZKe+LGsIpt5bFAs1LHIMBUlTCsuVIq2lD3TmScWbELn+Ace7WwKc+08GqOWZzUot5fkiIx3 /crnd7HTmUfqi0yCylHY62wxggOpMIIDpQIBATCBojCBjTELMAkGA1UEBhMCSVQxEDAOBgNVBAgM B0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xIzAhBgNVBAoMGkFjdGFsaXMgUy5w LkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMgIQaXxCJB0Ilpsxesw7IHRfgzANBglghkgBZQMEAgEFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwOTA0MDk0MTA2WjAvBgkqhkiG9w0BCQQxIgQg mQDvZ5W803RAicLFOMalAgFvA/juzfptUsm96FPEayYwgbMGCSsGAQQBgjcQBDGBpTCBojCBjTEL MAkGA1UEBhMCSVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8x IzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMgIQaXxCJB0Ilpsxesw7IHRfgzCBtQYLKoZIhvcNAQkQ AgsxgaWggaIwgY0xCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UE AwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzICEGl8QiQdCJabMXrMOyB0X4Mw DQYJKoZIhvcNAQELBQAEggEAJpRspn7atUxgvnmBJ7D4Q+kW7QZTAaRgKhj1N5dhoQleQja2KyBG aubqA/m8sVG4GRjv9RN+herjTj8eEYoaCAaB05Cl2Um40Ui6WUr1N1Hqv1elGoqBGQ4HboWZeAAu +2mYgLkF4Bv3e1kIcnnnnmJg63/ixT8eP8HR7aAYa5kTD5fDSf658LidocDGg6p1nYlJlWFopZG0 JFN+uGi9+Th24WJFaQ5BJTQz4SXPOpFXPMbuGE+BSVAr3yGf2KIaZpuLNN7iuJlwxuTUI/UiLFvx pqs5SZsw7+3eQI4IIiZ2Pm8Y7p5hkRXOJaV4dQfeV6EEVH3//UhMn6oOu1EE0QAAAAAAAA== --Apple-Mail-2CEECCB1-59C4-48C9-A46F-3862996FAB7C-- From nobody Sat Sep 4 07:13:57 2021 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 91B793A1818; Sat, 4 Sep 2021 07:13: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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <163076483550.10887.7902050812448217105@ietfa.amsl.com> Date: Sat, 04 Sep 2021 07:13:55 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-12.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, 04 Sep 2021 14:13:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : JWT Response for OAuth Token Introspection Authors : Torsten Lodderstedt Vladimir Dzhuvinov Filename : draft-ietf-oauth-jwt-introspection-response-12.txt Pages : 19 Date : 2021-09-04 Abstract: This specification proposes an additional JSON Web Token (JWT) secured 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 is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwt-introspection-response-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwt-introspection-response-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 4 07:21:10 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DA63A184B for ; Sat, 4 Sep 2021 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2RZ9cKpgxXf5 for ; Sat, 4 Sep 2021 07:21:06 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0763A1847 for ; Sat, 4 Sep 2021 07:21:05 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id m4so3366609ljq.8 for ; Sat, 04 Sep 2021 07:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=/qQ00A9H7SkNgNZTwg1WZkJ6GF9Aw5mf1rOb8jSB1NY=; b=Rrahndpjz3MTobkjQhpJNiFUh1Oyl2/m4YYCg8d6uCivSRv5CmlSYgLS6igPDsiQ7e 93ZlRrY/myqdHU5/tlby5lJMrS1z8SYp2GSqPS27ONR7a9jdFYzyfk6OGnAVEJQfa1JW Bjz5uQEdUUUF8oOSCKmeAdLwmbbFH5XwN3XigCK1yB7Zrpbh1YlucDOmEESHEicJBILY G54RpCx/g+CRjnsM6KpkR1DGUSba0n2Ep/cxWrsRfM7e19u45Mubco/eAnWhUMhSsqLP /xVDXP2UWZVYMokMiE2QxL2w5vbjayHVya/yPu+ps+lHENvgq82OUCkyybgC4dy0Qcqi B1dQ== 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=/qQ00A9H7SkNgNZTwg1WZkJ6GF9Aw5mf1rOb8jSB1NY=; b=Z2rqZpw8DkncaCL9c0MaJOYvjjqThsE6sUt2Cp9QzvC+E8R8xeXL3qzsvYFx4BkWmI 4TddRHtcoA+Vk3uYC8MLEs570hD5O1AK+gUcYCS7kdxtjZ/SX+CG39h3Heg59GaGiWLv D+pwTz7GJVLEYlw3oZpyevhW/GaivOwDxGvAHcNy0G9MqoflKL5/rLtMjj1U455tVE0e cv5trcykeQleZ6Ic7uApFbVxDvBYKTrwYGV1/GQBn2zsPOa2AT4wA/VBe0ye60He7D1M c5F6/DuBmUztxikfAQXh5zopHDIAaqtrYAIWDrj9uVi9HxbyoOJg0OlNiTeBWbZHgKWS 8t/w== X-Gm-Message-State: AOAM531sNm1Hp1NL1/u4SzI/W5h4MO1lNOpyNO1EQAFJG2nZwjGacYDp 7sXiAXJoO5gRMr/1206CK6o0tXRsJtQOMkpBCbk5vyEKvnc= X-Google-Smtp-Source: ABdhPJw/kLfkg9q1uZ5xRUrns2O68S2uV8zYRwAMPUBkTGQQdp1aFxLjcXLl1kZ0rbDt5eLulRVENi1qhL6OWu3HoLY= X-Received: by 2002:a2e:b8d2:: with SMTP id s18mr3032782ljp.529.1630765262149; Sat, 04 Sep 2021 07:21:02 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sat, 4 Sep 2021 10:20:51 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000299da505cb2c206e" Archived-At: Subject: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 14:21:09 -0000 --000000000000299da505cb2c206e Content-Type: text/plain; charset="UTF-8" Hi Karsten, Daniel, As the document shepherd, I have reviewed the document and I have the following comments on draft-ietf-oauth-iss-auth-resp-01 version: Section 2.4, paragraph 3, first sentence: "If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients SHOULD store the information which authorization server supports the "iss" parameter." Why is this a SHOULD? "Clients MUST reject authorization responses without the "iss" parameter from authorization servers which do support the parameter according to the client's configuration." What should the client do when it receives a response with "iss" parameter from an authorization server that did not indicate its support for this parameter? Section 7 RFC6479 should be replaced with *RFC6749* Regards, Rifaat --000000000000299da505cb2c206e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Karsten, Daniel,

As the document shepherd, = I have reviewed the document and I have the following comments on=C2=A0draf= t-ietf-oauth-iss-auth-resp-01 version:


Se= ction 2.4, paragraph 3, first sentence:

"If clients interact wi= th both authorization servers supporting this
=C2=A0 =C2=A0specification= and authorization servers not supporting this
=C2=A0 =C2=A0specificatio= n, clients SHOULD store the information which
=C2=A0 =C2=A0authorization= server supports the "iss" parameter."
=C2=A0 =C2=A0
W= hy is this a SHOULD?


"Clients MUST
=C2=A0 =C2=A0reject a= uthorization responses without the "iss" parameter from
=C2=A0= =C2=A0authorization servers which do support the parameter according to th= e
=C2=A0 =C2=A0client's configuration."
=C2=A0 =C2=A0
Wha= t should the client do when it receives a response with "iss" par= ameter
from an authorization server that did not indicate its support fo= r this parameter?


Section 7

RFC6479 should be replaced wi= th RFC6749


Regards,=C2=A0
=C2=A0 Rifaat=C2=A0=C2=A0
--000000000000299da505cb2c206e-- From nobody Sat Sep 4 07:26:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864E43A187B for ; Sat, 4 Sep 2021 07:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0OXH3BPVTP7V for ; Sat, 4 Sep 2021 07:26:01 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4653A1878 for ; Sat, 4 Sep 2021 07:26:01 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id k13so4253072lfv.2 for ; Sat, 04 Sep 2021 07:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=EQQjaoJKP2RmhBN7DhCCGmbPfQMUXNDKhTC8FVJ5wdA=; b=igW0rgilctdomaXZzZvsriQ1D6GiOBGcbwkjUj2/5ZGH5OnjoOhe2/kgwt2RYW8MRA vEQlJGSnLkHSdyJFqHR761oIYp/620cfFk/agOsEA7uAorNO2/kBqGlbWbSeGjZi5MIn awXW3lSACk0vIYsjM3u7fIwl/5+zHnWBELpTGFSynMvIv3zCS2BkFGAC2y2AbLP4ryuf ufq7A+A85h1lYkRTLQfwVo7QXAlqqEfiOZdliz/tm2Gs/Kl0ARNWmr1KPdFKYjmVr7cr ttgNUgkGDXmVCKbLLH4pKFdytmoy5HNVUYPuHH77nThYOVaCGqlrfu+7enTqtCnPg3Ao cvnQ== 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=EQQjaoJKP2RmhBN7DhCCGmbPfQMUXNDKhTC8FVJ5wdA=; b=WrNhisYfj0bXky663ZCJueQpcPcTy9hdSG9PRA5NsI8xX1jodaw3ONKZnc4EwmSV/r RGJ+v2r9b/aYku+oaF/znr8b0dAV6kOcXhsC2Su1T4BdPTmFo0Ke6KW2Ihmou2juxChT gpPBwN7egdCrGc/Ldrif7zD10BNzVqyVrEgQ0sdKTfWUIyxGfHVDchP7xpbKUMdL4Orx DSq1BpxC2Cen90qNo4LigXi9izn7+F0Jn5fpI10gTGwzK2srg/muzK0SnkKHIzOV0mvI tvLuZBTgPkYADnpk8r+YO8rWphf6M7UYPDmBmH+ulJBcmCid4K2G5Tf+qu5GM7tjFVOw Hxyg== X-Gm-Message-State: AOAM533wtAVVgxqcWhQ39ESUCJwMhAA2KHlstiABiw5OQJ4xFu/epjAV Emi1RKqvkfWpPgEBYOca7HfsYaTmVD936e8y33wP8tgRffQ= X-Google-Smtp-Source: ABdhPJxDDsiJHf1yA2Mo5Z5UWjBpVcPirD4kpdGltgKMoBGk/Z5b54V/YChA84c2z0NiNc+rksI1/VTF5Ab4iFjo0d4= X-Received: by 2002:a05:6512:2202:: with SMTP id h2mr3131559lfu.494.1630765558095; Sat, 04 Sep 2021 07:25:58 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sat, 4 Sep 2021 10:25:47 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000cd61c705cb2c313d" Archived-At: Subject: [OAUTH-WG] Implementations for OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 14:26:03 -0000 --000000000000cd61c705cb2c313d Content-Type: text/plain; charset="UTF-8" All, As part of the shepherd write-up for the OAuth 2.0 Authorization Server Issuer Identification document, we need a list of implementations for this specification. Please, reply to this email on the list with any implementation details for this document. Regards, Rifaat --000000000000cd61c705cb2c313d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As part of the shepherd write-up f= or the OAuth 2.0 Authorization Server Issuer Identification document, we ne= ed a list of implementations for this specification.

Please, reply to this email on the list with=C2=A0any implementation=C2= =A0details=C2=A0for this document.

Regards,
<= div>=C2=A0Rifaat

--000000000000cd61c705cb2c313d-- From nobody Sat Sep 4 07:30:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814C83A161F for ; Sat, 4 Sep 2021 07:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2MsOuqHI0ofP for ; Sat, 4 Sep 2021 07:30:34 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040BF3A1378 for ; Sat, 4 Sep 2021 07:30:33 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id m28so4252890lfj.6 for ; Sat, 04 Sep 2021 07:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=QuWvc4NIifhHNNv6dX/l4qezTIPX1CoZf6ZqUNlAQoA=; b=nYTAg9OsfNAWdC+cHmLtAZRo4lK0PZZQaYz3EXD5esRRmubwhw1R7uOEzNX2qsb2VR KCT16X4spv8alGdQzgGIYIdfDlTOpydgTFCUMT08mtz8/Fc7NDu/WzQc5tmhI18cTzjN 2zp7GAf1C/PnnTdv4utDMjJO/o4+5PdlogmazhwZMfbn35DBEbOTIkHbQyO5Bj5RpSUq A4fw3KCu0D7XVCLKkhY7KcHBrtnoI7lUQ7Jfbm3fjZ96vsRppYZ/mbMYALPh0xp9MiXO 1GCDy6pyo/iGSU3viqTsAwBkGX3aYFBwIcTzJ72QEWOLIBKI9HAG6YBrzPobdDZji9qi lRww== 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=QuWvc4NIifhHNNv6dX/l4qezTIPX1CoZf6ZqUNlAQoA=; b=GeV6R+x6b0sv+wBY29A9CFA179y2XTKiAu/DLTljb4MpPLQfxnD5+JVzdryAZKsljS 2/g0aB1w1lYD2U1i6v2R1LkG/mb8Py0Uu5/MNGT+JOxJ7TRI6YUBTVGb5wuF6CN4HpGZ VVNBLwouHw96C/0LXxI8ZdOqK4Q3eXfPIzziPfviDYeux71OAlnYT5f+dFPtErNQbiAX 915yZX6VyVMP/DpnMHHXghG1V0bt3Fe87sUyYOJNDgGpUBakCjdM6oh+Oeu2p5L+AKzU PnXhHQbsIkTbVpQ+bLkxkESc8FljY2cUvOQuCT8y4To2rSz/yfYTEPwi1o15fHNAZxUy 9yHw== X-Gm-Message-State: AOAM533LGyEQ2CSR3g7SgAfvakSUnpzaIHt8mS7777oX3sS39ZpQ4I+X 7TiBxBNRdAXye59O9eFJ5+pOU9ywRe4EPHzods9V8KbsPIM= X-Google-Smtp-Source: ABdhPJxTFF3Tmp2ylwWHnR03REoJ8UAJnwCjLIbdH0JXgNiE2uySsuUuQ21zFG7Y7MF+8iDC/wYl1i9S/bLXRq7yZrY= X-Received: by 2002:a05:6512:2307:: with SMTP id o7mr3236484lfu.352.1630765830003; Sat, 04 Sep 2021 07:30:30 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sat, 4 Sep 2021 10:30:18 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000025fe105cb2c42fb" Archived-At: Subject: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 14:30:36 -0000 --000000000000025fe105cb2c42fb Content-Type: text/plain; charset="UTF-8" Authors, As part of the shepherd write-up, all authors of the document must confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Please, reply to this email on the mailing list and indicate if you are aware of any IPRs associated with this document. Regards, Rifaat --000000000000025fe105cb2c42fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors,

As part of the shepherd write-= up, all authors of the document must confirm that any and all appropriate I= PR disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed.

Please, reply = to this email on the mailing list and indicate if you are aware of any IPRs= associated with this document.

Regards,
=C2=A0Rifaat

--000000000000025fe105cb2c42fb-- From nobody Sat Sep 4 08:22:47 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02103A1A3A for ; Sat, 4 Sep 2021 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BbQekef7sXDv for ; Sat, 4 Sep 2021 08:22:43 -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 699953A1A33 for ; Sat, 4 Sep 2021 08:22:42 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id p15so3545046ljn.3 for ; Sat, 04 Sep 2021 08:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=MXO854Uq0EnJ8Nx/G6qw3p0Yvt5jJ2XxI0E8/D2pt+g=; b=YlfxBTPFIwr4vpwBEI+8txRIeURv/pHarFPGQW9BllT6Vh+SRZv4V9cU/yC2PFCWXZ /oZ7gzis0tSnBpL8J+fxOVKf6sPc7D3fHWqQOYEO0BBh4zW53JjSJtExiEojghTHbKah zyZNqIjJLEwo2ByJm0T13VGqFBeOLYz4WFBmA19AAWF0AhqtWEnbrsvWJnVtdwnyqD2A uNWDHVOg+lyb2Lm0FOY4q0LOadAM2LVg0RVxJmha51PPhcIXLDuF/gI1tYh0UgvIJ+OK ecKL14snSwAMPZVD49WtGwaBW7xpTbnu/BbCEUWCpyKYhmCO5ZbT1dMfO8PlnzFBoavh pwkg== 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=MXO854Uq0EnJ8Nx/G6qw3p0Yvt5jJ2XxI0E8/D2pt+g=; b=NqTLw+8MUUzB7zRZ3JbbyEVWhkD5+fnrPStw06Fo3FF5vZfsVMV7wUIa4Iao1t1sZr PQWxcXgsQ23id8Guqt8Mv+Z8HRZMVlcghSZGWXK/zpmyogELsA3YDf/Eu1gOfiXtRkjZ NwEwDLHohVdIasQ9WFiBBnnzsStSfxIs1LTX8EoJkZdz6wAeiHFQHq5uCXmRZlBK1yrF 5Mzc8R3GHCg0oUwrCQtYuQBXsyP3RcsyiLmwCsb5a7Lq2O1A8uqQvf58qYwQkVcD5V9M Yn3ZyyE9pTNi3YE/ARGf8YuQWSWKvkPn8G6aIbjEsEbjpkWZgOn5fyYLBKZSRLLuO2uv aQBw== X-Gm-Message-State: AOAM532/NekH1Zpw3KVQp6whIFKfme/jTl3N6pfhhP3X8zCiiJzLYJO9 jvyIaGVotkbUbIZdt2QGknk63+443hRMKBp+pNkT6SPK X-Google-Smtp-Source: ABdhPJyIH6nnq7/tIKQCayaHHvjuGECnVniGEWGM4OoRSvzyF0K7dOp1A56F2pB7Gr6/BTV0jXibWS/6Oj5Zlrz6pwA= X-Received: by 2002:a2e:96d5:: with SMTP id d21mr3340678ljj.285.1630768958966; Sat, 04 Sep 2021 08:22:38 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Sat, 4 Sep 2021 11:22:27 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000828fa505cb2cfc2f" Archived-At: Subject: [OAUTH-WG] OAuth Interim Meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 15:22:45 -0000 --000000000000828fa505cb2cfc2f Content-Type: text/plain; charset="UTF-8" All, We would like to start a new series of interim meetings later in September. Please, let us know if you would like to present during one of these meetings. Regards, Rifaat & Hannes --000000000000828fa505cb2cfc2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

We would like to start a new serie= s of interim meetings later in September.
Please, let us know if = you would like to present during one of these=C2=A0meetings.

=
Regards,
=C2=A0Rifaat & Hannes

--000000000000828fa505cb2cfc2f-- From nobody Sat Sep 4 16:26:51 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873A13A1849 for ; Sat, 4 Sep 2021 16:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9TyFeGGhQaeB for ; Sat, 4 Sep 2021 16:26:46 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F5B3A1847 for ; Sat, 4 Sep 2021 16:26:46 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id c206so5772392ybb.12 for ; Sat, 04 Sep 2021 16:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=4OhPfehccBbgWoq+T8Tik9X1OwSEg3BBWXy0qIEde2o=; b=H7Ecb5NcIJalmpRRX55BwJJicYPyvt2VvA3ZIhcLVAnZ2toSeqAIIIaEOHZIaSvn+A U+dlz/kDxzXav/x6MSPJPoU+eNKwRml/vhk7S0GR0NkiQkUY8S0tuRrrJfPgZztca1gw sUu3DUCBSqWcG6rICFSrnh1ZphJhlVSdXqEsAxplWdmC0hSt8b0aBpFHfM9jSJqKppPs JYXo8/YUaBiiyUXZEXxoX9sX9/rIcZaLb+juC+XoElVHvanVjpbG0J1j1If5Sf4xVq3N 2P9B3t52d5FD/ayen1vKoWD0KEFEtbpPppvADfVQ6GyyczZjeiJHP3zFJHaoNI0corg5 czqw== 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=4OhPfehccBbgWoq+T8Tik9X1OwSEg3BBWXy0qIEde2o=; b=HhfvSpT1Kse1G1bCLwa9kNgdSmx1c9XAxCObXzwBIGmY3J6KnHyaKuBueGGUe7MYkE gcxymPFXMDvIntNOx+NpwbMqx0gElUMDD81Gl7W0cl2LKFhm14m6tunQZT74Ytq+OisH e5C2M2H0Mp9XaeNYgb+3guQIGBmx0agoqGQWNoG5Qjly1z0KGwA5U1saW+4gSdHjtTfH k5tBsj6TWCb36xFU4GKBDCso2RTlBuoV2aqnOZ0Ms8ZOC7ITKZCPNV2n08yZNZmufciZ G39VUCs1Gh5opQOKg0CtP0mruwpSmj0hHCjmfvfA9hL/e79SgaNVeuJRK+pVQ6F/df7h IACQ== X-Gm-Message-State: AOAM531qxfAGI248EUWbTcT9uQB9Wm8iJYc2Jt3al6HblVj/512JQWzQ wZBtCPa2lozmI4wjiXMVlptMETI9hhy+TbIbAfShTPZA X-Google-Smtp-Source: ABdhPJzIgYNzuzC2XdxLXY5For+u35g8E8oxLgfINtkwn9RjQuNua5yoYatdblKKYZmw3BJXMKLueKMp6s0pvu5FTqM= X-Received: by 2002:a25:1d89:: with SMTP id d131mr7219549ybd.430.1630798003888; Sat, 04 Sep 2021 16:26:43 -0700 (PDT) MIME-Version: 1.0 From: Thomas Broyer Date: Sun, 5 Sep 2021 01:26:34 +0200 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000b8e7a305cb33bfbf" Archived-At: Subject: [OAUTH-WG] Spam apparently coming from my email address X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2021 23:26:50 -0000 --000000000000b8e7a305cb33bfbf Content-Type: text/plain; charset="UTF-8" Hi all, Someone's apparently sending spam through this list using my email address as the sender. I'm obviously not the author of those. Could some of you please send me the full spam mail (with full mail headers) ? Thank you in advance and sorry for the inconvenience but I don't think I can do anything about it. --000000000000b8e7a305cb33bfbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

Some= one's apparently sending spam through this list using my email address = as the sender.

I'm o= bviously not the author of those.

Could some of you please send me the full spam mail (with full ma= il headers) ?

Thank you = in advance and sorry for the inconvenience but I don't think I can do a= nything about it.
--000000000000b8e7a305cb33bfbf-- From nobody Sat Sep 4 19:52:52 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965B63A0365 for ; Sat, 4 Sep 2021 19:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVP-WrVLoB1u for ; Sat, 4 Sep 2021 19:52:46 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17D113A0332 for ; Sat, 4 Sep 2021 19:52:45 -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 1852qcos027170; Sat, 4 Sep 2021 22:52:40 -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.1497.23; Sat, 4 Sep 2021 22:51:50 -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.1497.23; Sat, 4 Sep 2021 22:51:43 -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.1497.023; Sat, 4 Sep 2021 22:51:43 -0400 From: Justin Richer To: Rifaat Shekh-Yusef , oauth Thread-Topic: [OAUTH-WG] OAuth Interim Meetings Thread-Index: AQHXoaCdM0uVqm4ddUykbQZAbh2ZBauUvlFm Date: Sun, 5 Sep 2021 02:51:43 +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-transport-fromentityheader: Hosted x-originating-ip: [172.58.173.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2021 02:52:51 -0000 I would like to present the proposed HTTP signatures draft, and separately = I think it would also be beneficial to the OAuth wg to present an update on= the progress of GNAP.=20 -Justin ________________________________________ From: OAuth [oauth-bounces@ietf.org] on behalf of Rifaat Shekh-Yusef [rifaa= t.s.ietf@gmail.com] Sent: Saturday, September 4, 2021 11:22 AM To: oauth Subject: [OAUTH-WG] OAuth Interim Meetings All, We would like to start a new series of interim meetings later in September. Please, let us know if you would like to present during one of these meetin= gs. Regards, Rifaat & Hannes From nobody Sat Sep 4 20:19:53 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3ED63A0865 for ; Sat, 4 Sep 2021 20:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7b22g7i7vRYF for ; Sat, 4 Sep 2021 20:19:47 -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 0ED3E3A0864 for ; Sat, 4 Sep 2021 20:19:46 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id a15so4121792iot.2 for ; Sat, 04 Sep 2021 20:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8JNB5bRCkQz3XmuiFNSBglwLjyR7H5rnwyvCgJMBUII=; b=CG8cMACdr0+u7zeKxW1MgUPMP+OtIyn4moaK0yPfcAJLore91RAQNePoytC0xTSHgI sdODxjI1KDGFzTWlbxL5500yozetddwASy6fHVOpPSQeYgWy7iLiZ5gvW53xj+iFPKEi LNcqoggbSpBBVsmDkDaHuWgFxI7K+ctVCpEujXtkwo7wMJNG2/xi11nzzgE4wZ1Uqbde EID/npGHVcCqzOhEvC3vaHE1zqB8yN5Ww49o+BSPGcN1p6KRXPeP9HAl0JWSxRo35xt/ SNc1GsZ3+bIWGpqxi0MEFVB4ZHsJbhGzcZL5RYoA3TtfgUMOmXUnO+urcbl2s9k4lbfx kFLw== 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=8JNB5bRCkQz3XmuiFNSBglwLjyR7H5rnwyvCgJMBUII=; b=SV9m1kOe8XPuyl5U8PQf9jam3bAw3OOgAPuNsrDQIMPo1aSBsyZmblfc83x8IF7cu+ Few84fsQY+LgWFB4rqNKVZzvwRA2J285ZtaqEjwNJaVV+MSFZd7L1dnFvUuGTUxzWJb6 ypcGS3FUrRhLxshlF7ashX0FA4g3oGPV8EeDSS8Ea05N1LENoG+9r3RyoMlDtTcDslAG adAuU8x5LZp6918kPDfE25JoYVfBsMSYwGm96PgqXKHkZIUsJbibWCblUp0Kr+EypnCS GCQPD4xUy9lSxevXdAxPeOcv+dC+uinPMx8T3U1mssMCIyNWwRnUMkJveRGQwgnkyHrk 5y1w== X-Gm-Message-State: AOAM5324/ZS4e8Gt0qQBT3x/e63FHgeGCsfW/NYXu4x/X2vqKjgjR1zZ XywJeXnONHZOxXu/DzjrXZJP90sW16PRkg== X-Google-Smtp-Source: ABdhPJz/29cSDutzmKgZYc4nELWoX1Vyan3HZ02coWuVEIjPEZlSgWtWnWUGGigNPj4TGxn7Tg6igw== X-Received: by 2002:a6b:c80f:: with SMTP id y15mr4792566iof.80.1630811984616; Sat, 04 Sep 2021 20:19:44 -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 v5sm2364816iln.42.2021.09.04.20.19.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Sep 2021 20:19:44 -0700 (PDT) Received: by mail-io1-f52.google.com with SMTP id j18so4094945ioj.8 for ; Sat, 04 Sep 2021 20:19:43 -0700 (PDT) X-Received: by 2002:a02:2341:: with SMTP id u62mr5384272jau.6.1630811983553; Sat, 04 Sep 2021 20:19:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Sat, 4 Sep 2021 20:19:32 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f9aa8b05cb3700c9" Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2021 03:19:52 -0000 --000000000000f9aa8b05cb3700c9 Content-Type: text/plain; charset="UTF-8" I would like to present on OAuth 2.1. Separately, and preferably later in the series, I would like to present on the Browser App BCP. Thanks! Aaron On Sat, Sep 4, 2021 at 8:23 AM Rifaat Shekh-Yusef wrote: > All, > > We would like to start a new series of interim meetings later in September. > Please, let us know if you would like to present during one of > these meetings. > > Regards, > Rifaat & Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --- Aaron Parecki https://aaronparecki.com --000000000000f9aa8b05cb3700c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to present on OAuth 2.1.

Separately, and preferably later in t= he series, I would like to present on the Browser App BCP.

Thanks!

Aaron



On Sat, Sep 4, 2021 at 8:23 AM Rifaat Shekh-Yusef <= rifaat.s.ietf@= gmail.com> wrote:
All,<= div>
We would like to start a new series of interim meetings = later in September.
Please, let us know if you would like to pres= ent during one of these=C2=A0meetings.

Regards,
=C2=A0Rifaat & Hannes

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
---
Aaron Parecki
--000000000000f9aa8b05cb3700c9-- From nobody Sun Sep 5 07:50:15 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0514E3A1AD9 for ; Sun, 5 Sep 2021 07:50:09 -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, 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 vo0hYtMlZ4Ek for ; Sun, 5 Sep 2021 07:50: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 7F6EC3A1AD7 for ; Sun, 5 Sep 2021 07:50:03 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id b200so5370745iof.13 for ; Sun, 05 Sep 2021 07:50:03 -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; bh=oXLbrGb31KgLALTIpaUgVKR4Mnc9YIiomI0W/yboSn0=; b=pvd3rJStdm5qlbBIrjffKuHDw1GOptwq/H054/Qf7Aqimk0jS9OpqiExzuQsFNK3gn /rHd9ly1zJMKtAWmZjGUDIpWeZofHqJLNSL5zL+EN68JZmVxZ3Lr3ozxig4cSEUkbeWo w+ZhKevjfk8KurSVuilckPkBy/eyjHZAjVLq1/m7xuznURCpAjeesi81PVsic6hKV5iR KZq4dGwLQanLwQGoArzfzKIWdsDAPut9572QYAyDWQu75xutnYp6XV4Yf99sOmUK6V8u t5yoGQdNLyy/b9+qn/oKJD+X7bNCSg5EGwnmlGhO1XDfzf7caRUzhwHVhj8xWl9+p+vr LITA== 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; bh=oXLbrGb31KgLALTIpaUgVKR4Mnc9YIiomI0W/yboSn0=; b=Z3syJOUiNGYmyvyUd/jepQVBPARVB3EMrBKkin2AGlSlt1HAiRTnu0mTUJAN/IIsPG GrTjGQXurKT7rQD8wBALKPxy1r6nptfGZklzqsjz+HWWJVmiH/qQg4RDE7EU91XvJaLA 1BQN8gGRXEG4KeNoSXBSozBeyMG/55FmDQGXc9kQJL5nbVn4EoA5Mv2RQPrKzahC/oZs rdwBXkEBVUwiuFYl+UbD63Sqlh701dc4IxMQ3XBSkX3smOevFKp6x938G5IcQ2RKfHzR oFfsr2NSxETj47Zr4oUPWMySiEJQfqXIHZLFE4aINen6VZNKVkB3PQR1fe9m2uBJMSVn IE0A== X-Gm-Message-State: AOAM53292F8z5z7XV18SsTU8l36GxCcSpggOY1Yzl8hWKFBgFPMW7Dzd /ty9EQ5iP1bc9sm3LFzchuliCMWapB4vd28RxQap X-Google-Smtp-Source: ABdhPJwvj38SHlMMNY8QOv1W/n3nCqf3c8aXQIOJJ3+sahRM4K7iHLgJbICrF68lVpXSIH/LmXogmx5MBEt0ORucUw4= X-Received: by 2002:a02:9698:: with SMTP id w24mr7076989jai.108.1630853401296; Sun, 05 Sep 2021 07:50:01 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 5 Sep 2021 07:50:00 -0700 From: Dominick Baier In-Reply-To: References: MIME-Version: 1.0 Date: Sun, 5 Sep 2021 07:50:00 -0700 Message-ID: To: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="000000000000aa550805cb40a505" Archived-At: Subject: Re: [OAUTH-WG] Implementations for OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2021 14:50:09 -0000 --000000000000aa550805cb40a505 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have implemented it https://duendesoftware.com/products/identityserver =E2=80=94=E2=80=94=E2=80=94 Dominick Baier On 4. September 2021 at 16:26:21, Rifaat Shekh-Yusef ( rifaat.s.ietf@gmail.com) wrote: All, As part of the shepherd write-up for the OAuth 2.0 Authorization Server Issuer Identification document, we need a list of implementations for this specification. Please, reply to this email on the list with any implementation details for this document. Regards, Rifaat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --000000000000aa550805cb40a505 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
We h= ave implemented it


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

On 4. September 2021 at 16:26:21, Rifaat Shekh-Yusef = (rifaat.s.ietf@gmail.com) wr= ote:

All,

As part of the shepherd writ= e-up for the OAuth 2.0 Authorization Server Issuer Identification document,= we need a list of implementations for this specification.

Please, reply to this email on the list with=C2=A0any implementati= on=C2=A0details=C2=A0for this document.

Regards,
=C2=A0Rifaat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
--000000000000aa550805cb40a505-- From nobody Sun Sep 5 09:12:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E726A3A03F3 for ; Sun, 5 Sep 2021 09:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=authlete-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnzvxXQq6YOn for ; Sun, 5 Sep 2021 09:11:55 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED073A03EF for ; Sun, 5 Sep 2021 09:11:54 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id 79-20020a1c0452000000b002e6cf79e572so3212868wme.1 for ; Sun, 05 Sep 2021 09:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=authlete-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X8zk9Wgpdy9bKtRNLK2hyjxf3aBjJVh8jjI667EmYNg=; b=D+DEgr094KSMnoshdc57M2iFrH3TyC8caR/dpWTJKG9nQt8xjj2Z0+2EzC2pHVTUuE a1mvczg4fd0HCX+uxAa3+lO8jDNK/umck6gCwolUj50atguy8+t5C52KikCi68izns2j +y5zF1jZMpTQQnQ0UbLpYA6NahSFg0FQiPFXo2Uk4T5S7GTj7X6x5+hfZjoNFwKOLvza DahQ1zmBinWjAbTrsi0M8pJP1kYOd19wS4gL56EvpKaPwpkoflpzVMM5oj0A+TxCJDcc cSncHhiZovOE1zu6nsUiknQoKOrz19YecfDY8DcA4BY5s9Ol6X9AQlzv3DeeCu/cauwk Fhcg== 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=X8zk9Wgpdy9bKtRNLK2hyjxf3aBjJVh8jjI667EmYNg=; b=ldlznGQhk3R23TXPWQznXBLLgsu1vkBysIGIfgvJUblLzBYNhupnqthMEdCGUl+KAY ioYkIVFVjw8V4pAivN29BRjKWk4SLGdqhudYqF+4Y4V9sYWgpxEyrBqVXnmt8ITK+kkL mogssU53OmzA6KseOrx4BXGucdZpUTkP9Wr1XbxGLdVH4dSjk1w4k2F58dZ1yyCoMx35 52tSXtlpfckKN+lZ8CucctQIaZVTjHo1KBzbbAAdVxc3FWOSR3SP9B2D0dzgh5mDJ9ED roszdQ30j3jhqhuC8jRC4w6AF442iCORdjb1VcQYIduFqOUJJVrJ3kbqSHEJ3diHB5pw 68ww== X-Gm-Message-State: AOAM532NoQAdWsuBnlQAby8LkaiuU58IdF8O87yOk31aTqlpv359kScr I5rQS/Ksws95CZTsLZ31DQddYGdlCVTywSnQmAIkeg== X-Google-Smtp-Source: ABdhPJwRd47gngJVm8aLL/B84XrRrF52+lFeg15jIwB105cyNR6RS/MtuRXa2+lijB12S4VloYH+yK5z4/I+EZ0mHe8= X-Received: by 2002:a05:600c:4293:: with SMTP id v19mr7586965wmc.32.1630858311471; Sun, 05 Sep 2021 09:11:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Takahiko Kawasaki Date: Mon, 6 Sep 2021 01:11:40 +0900 Message-ID: To: Rifaat Shekh-Yusef Cc: oauth Content-Type: multipart/alternative; boundary="00000000000055ab3005cb41cab0" Archived-At: Subject: Re: [OAUTH-WG] Implementations for OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2021 16:12:01 -0000 --00000000000055ab3005cb41cab0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authlete supports the specification from version 2.2.2 (2021-Feb-12) onwards. Authlete 2.2.2 Release Notes / OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response https://www.authlete.com/developers/relnotes/2.2.2/#oauth-2-0-authorization= -server-issuer-identifier-in-authorization-response Also, I mentioned the "iss" response parameter in a certain monthly magazine for software engineers which will be published in Japan soon. Best Regards, Takahiko Kawasaki On Sun, Sep 5, 2021 at 11:50 PM Dominick Baier wrote: > We have implemented it > > https://duendesoftware.com/products/identityserver > > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > > On 4. September 2021 at 16:26:21, Rifaat Shekh-Yusef ( > rifaat.s.ietf@gmail.com) wrote: > > All, > > As part of the shepherd write-up for the OAuth 2.0 Authorization Server > Issuer Identification document, we need a list of implementations for thi= s > specification. > > Please, reply to this email on the list with any > implementation details for this document. > > Regards, > Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000055ab3005cb41cab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authlete supports the specification from = version 2.2.2 (2021-Feb-12) onwards.

Authlete 2.2.2 Release Notes / = OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response<= br>https://= www.authlete.com/developers/relnotes/2.2.2/#oauth-2-0-authorization-server-= issuer-identifier-in-authorization-response

Also, I mentioned th= e "iss" response parameter in a certain monthly magazine for soft= ware engineers which will be published in Japan soon.

Best Regards,<= br>Takahiko Kawasaki

On Sun, Sep 5, 2021 at 11:50 PM Dominick Baier <= dbaier@leastprivilege.com&= gt; wrote:
=
We have implement= ed it


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

On 4. September 20= 21 at 16:26:21, Rifaat Shekh-Yusef (rifaat.s.ietf@gmail.com) wrote:

All,

As part of the shepherd write-up for the OAuth 2.0 Authorization Serv= er Issuer Identification document, we need a list of implementations for th= is specification.

Please, reply to this email on t= he list with=C2=A0any implementation=C2=A0details=C2=A0for this document.

Regards,
=C2=A0Rifaat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000055ab3005cb41cab0-- From nobody Sun Sep 5 13:41:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9AC3A0886 for ; Sun, 5 Sep 2021 13:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=rhosys.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi7yxdIBms7i for ; Sun, 5 Sep 2021 13:41:25 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981C43A0883 for ; Sun, 5 Sep 2021 13:41:25 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id c206so9431320ybb.12 for ; Sun, 05 Sep 2021 13:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhosys.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yy4GF2J5b9cVRx4StndQxeoIo0jX9mK4bg0cI2XK5P0=; b=c+HQTXMmk81PELu2ymVfZK7dTzAoI7LPnnnPmlm6ue5VGtC7r4qVoTSvHSaP+9ndVF vjSMVTE7+UYxjDYVSnoy+VslHVb6ywipPmfveS1mILyoRWB1ZznGnl+B2S3nuciOK+wG lDL6e0SKayjroITS6Ew5Ik0Q6X5Jxf0MK5BsVW2u4KH1cyc53pxINWBYa6N0yaG4sMYr yBQiI0uoWTQZHCGydeZ297TzvxagTEu7OQtQ2CkozeJrUh7PHtwQnK+/IKaFbgzfVWAG buH2Tf+o6ggNilyO6ZyQ9Gt/KiivOQ4ALFvbijxnaCujRe2A13DklXjigJ9QVuzz0Jpw /eWQ== 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=Yy4GF2J5b9cVRx4StndQxeoIo0jX9mK4bg0cI2XK5P0=; b=lR7y4uk0G/xA5kI2ig1LM1lis4GDmImIk/N8ZhbJqYFPk4LF0gpGr35p143pd4d8bz ULtv//4dNsHlM/lNp60ZsK1H81KSnX7S3+Gbb5HOU5i+yM0cQg5SSVp+GG/CTYn7lNoV pqnLZZV0bonNS+rTxKofrRrRSjourtJAHU8yP62Aryx5g08yQN9C+uTaU1TAm8/o3dbV U+aD7m+eBFq5kXUzBN8LeKWcthdzZkQPH1GAE99zF09fTR13iIajesNhDJ8KN+H1qXIA FDgRJNRj1kfssgEwwG+0Uy7TjJBh88doPf/8SQLguC77Zwpglc/FcMqsmKbVw/jipMDN dW9w== X-Gm-Message-State: AOAM530CQ6Gy5q3lhDQQ2dc1hv8FCEilmd0EnCa7BkKdHzcxVdDxYGB2 487YaujmCNiqWV9Kas6XVsPW316uzNUQ106u+pun X-Google-Smtp-Source: ABdhPJzGcz0XUrYVOBdQ4zj4kd4KzSBTFof21j+JaernEuiRztB6OVqLezb2nL/jJJBHGm1soq9ln11Y7nRNfkLVk9E= X-Received: by 2002:a25:be48:: with SMTP id d8mr11789861ybm.521.1630874483407; Sun, 05 Sep 2021 13:41:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warren Parad Date: Sun, 5 Sep 2021 22:41:12 +0200 Message-ID: To: Takahiko Kawasaki Cc: Rifaat Shekh-Yusef , oauth Content-Type: multipart/alternative; boundary="00000000000041d17a05cb458e12" Archived-At: Subject: Re: [OAUTH-WG] Implementations for OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2021 20:41:34 -0000 --00000000000041d17a05cb458e12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This has been implemented in https://authress.io. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Sun, Sep 5, 2021 at 6:12 PM Takahiko Kawasaki wrote: > Authlete supports the specification from version 2.2.2 (2021-Feb-12) > onwards. > > Authlete 2.2.2 Release Notes / OAuth 2.0 Authorization Server Issuer > Identifier in Authorization Response > > https://www.authlete.com/developers/relnotes/2.2.2/#oauth-2-0-authorizati= on-server-issuer-identifier-in-authorization-response > > Also, I mentioned the "iss" response parameter in a certain monthly > magazine for software engineers which will be published in Japan soon. > > Best Regards, > Takahiko Kawasaki > > On Sun, Sep 5, 2021 at 11:50 PM Dominick Baier > wrote: > >> We have implemented it >> >> https://duendesoftware.com/products/identityserver >> >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick Baier >> >> On 4. September 2021 at 16:26:21, Rifaat Shekh-Yusef ( >> rifaat.s.ietf@gmail.com) wrote: >> >> All, >> >> As part of the shepherd write-up for the OAuth 2.0 Authorization Server >> Issuer Identification document, we need a list of implementations for th= is >> specification. >> >> Please, reply to this email on the list with any >> implementation details for this document. >> >> Regards, >> Rifaat >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000041d17a05cb458e12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This has been implemented in https://authress.io.

=

Warren Parad

Founder, CTO

Secure your user data with IAM a= uthorization as a service. Implement=C2=A0Authress.


<= div class=3D"gmail_quote">
On Sun, Sep= 5, 2021 at 6:12 PM Takahiko Kawasaki <taka@authlete.com> wrote:
Authlete supports th= e specification from version 2.2.2 (2021-Feb-12) onwards.

Authlete 2= .2.2 Release Notes / OAuth 2.0 Authorization Server Issuer Identifier in Au= thorization Response
https://www.authlete.com/developers/relnotes= /2.2.2/#oauth-2-0-authorization-server-issuer-identifier-in-authorization-r= esponse

Also, I mentioned the "iss" response parameter= in a certain monthly magazine for software engineers which will be publish= ed in Japan soon.

Best Regards,
Takahiko Kawasaki

On Sun, Sep = 5, 2021 at 11:50 PM Dominick Baier <dbaier@leastprivilege.com> wrote:
We have implemented it


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

On 4. September 2021 at 16:26:21, Rifa= at Shekh-Yusef (rifaat.s.ietf@gmail.com) wrote:

<= div>
All,

As part of the= shepherd write-up for the OAuth 2.0 Authorization Server Issuer Identifica= tion document, we need a list of implementations for this specification.

Please, reply to this email on the list with=C2=A0an= y implementation=C2=A0details=C2=A0for this document.

<= div>Regards,
=C2=A0Rifaat

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000041d17a05cb458e12-- From nobody Mon Sep 6 00:53:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662763A2597 for ; Mon, 6 Sep 2021 00:53: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDlNkqV5eIM8 for ; Mon, 6 Sep 2021 00:52:57 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027C43A2598 for ; Mon, 6 Sep 2021 00:52:56 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id q70so11942041ybg.11 for ; Mon, 06 Sep 2021 00:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tC10d45iC2MIPAKp9xPmzoCG82yydZ8FLPY1hvWroM0=; b=lcK6N8OU89DiNazIlik7O6itHUmm/Qrs1zkN5909aqodTu+tA934bUquMXzd3PKX7C jFIEfOBRMIS8e097kQOvEEgUmyLcWBPLMo9G4GyjMxmh2kYtrQ6FykdpdziNNYT768AS SGnVqDrWueMswKFklVg0yOaxUgl52ATM+dsjGa8SW6O/QNxMo51gvjp5UNIC9xY6ZNd7 HrRLRYyQ0k+sCJf0Ux/+038avbtUHN9WCaIJI3G6SF613WlgyW69CMev2CS3o4KH/Ewk dxNrY29v6Huql0V46BA/YAEXtbhXfp/JGk0Sqqny4lzNvDDreCA974Mj6l1JiyIHnEWG wJsA== 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=tC10d45iC2MIPAKp9xPmzoCG82yydZ8FLPY1hvWroM0=; b=tFwLeYwbsLBPcpcVRL+4Mn1v8/SH38StSEaHD3zZQ0aRpCDWXc6qKz26OrazKSjPF1 BMnpRrc3EgUWu0Zm2ahs4FslPHDNYpRwsMKqQlkX5gEAQAAzGP7XEDjXACHFtEeEBRb/ onkrhaDJWxhKSJY+3M/lmoEELIHEJlZCY8yw+IRUSCRqRjtXB22hhFiPGFNcTc35Yew1 30Uuf/3dx61arE8utQiqJemi9bnVhV9S7qwxDBomoOZKCik7duDPuEvw+gB9ZPtVHcNt 7lJpUTD5pukjszwsJatxAXdpr2T2M9zkwPEROG5eYn1BjzlrIj9F6T0ABtCwozvUPIQY +yGA== X-Gm-Message-State: AOAM53036dQk2ko2OT4DBWAJwqdoZyr+5y9tbPD6I4xP4uuCxyDaBAqY xQ9PW/vzlZhT+kk8WaP2YwcuxGmmRqdsC7UTUwWNELHp0826xw== X-Google-Smtp-Source: ABdhPJwLqin6lM0jFMFH8Wuz+mYKJCUcI2fh6ZKVK3/oWEejpSCjb7K2ymcU9a8AEWrk2uSkhMzjaQ+VGoINutqwrrc= X-Received: by 2002:a25:c184:: with SMTP id r126mr13997796ybf.123.1630914775500; Mon, 06 Sep 2021 00:52:55 -0700 (PDT) MIME-Version: 1.0 References: <250c6a12d1ab42a4869a0a9689ad1625@oc11expo18.exchange.mit.edu> <0C5C7579-2979-4B64-8163-BA254B07CFC1@lodderstedt.net> In-Reply-To: <0C5C7579-2979-4B64-8163-BA254B07CFC1@lodderstedt.net> From: Jacob Ideskog Date: Mon, 6 Sep 2021 09:52:44 +0200 Message-ID: To: Torsten Lodderstedt Cc: oauth , Justin Richer Content-Type: multipart/alternative; boundary="000000000000da5e4705cb4eefb5" Archived-At: Subject: Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 07:53:03 -0000 --000000000000da5e4705cb4eefb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, privacy considerations could be more explicit about this. It should probably explicitly mention the token response and the Client. I also suggest clarifying in 7 or 7.1 that the token response MAY be less explicit or even different than the authorization details issued in the tokens. This is not simple, since it may lead the Client to think it has more (or less) access than it actually does, but since the intended audience of the authorized data is the RS it should be ok. A scenario I see is that the client requests Account access based on pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The AS replaces these with the actual account numbers ("accounts" : ["123-123", "234-BCD"]) so the RS doesn't have to deal with those translations. So: in the token response the pseudonyms are still used, but in the issued token the explicit account values are used. Suggestion for section 7: "The AS MAY omit, mask or hide values in the authorization_details to the Client in the Token Response if these are deemed sensitive and of no intended use for the Client." Something in that direction would make it more clear that it is allowed to do so, and that the Token Response doesn't prevent the issued token from containing sensitive data. /Jacob Den l=C3=B6r 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt < torsten@lodderstedt.net>: > The AS intentionally shares the list of accounts in the mentioned example > with the client. The assumption is the client asks for access to some > accounts and the user decides which accounts to grant the client access t= o. > This means the AS is authorized by the user to share this data. > > The privacy considerations section already has text about sharing data > with resource servers. I suggest to add some text re data sharing with > clients. > > Would that work for you? > > > Am 04.09.2021 um 03:12 schrieb Justin Richer : > > > > =EF=BB=BFThis is a fair point... The privacy and security consideration= s talk > about this a bit as I recall, but likely need to in more depth and > specificity. This is an intentional message channel to the client from th= e > AS, but if the AS is blindly sending all information it might be saying > more than it means to say to an entity that doesn't need that detail to > function. Scopes have similar issues, but this structure adds more > opportunities for mistakes just due to the possible increased complexity. > > > > -Justin > > ________________________________________ > > From: OAuth [oauth-bounces@ietf.org] on behalf of Jacob Ideskog [ > jacob.ideskog@curity.io] > > Sent: Friday, September 3, 2021 10:42 AM > > To: oauth > > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in > draft-ietf-oauth-rar-05 > > > > Hi all, > > > > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 > that describes the token response. > > > > The authorization_details values could be sensitive in their nature. Th= e > example in section 7.1 highlights this nicely. The accounts array is empt= y > when the client requests it, but is enriched by the AS and returned to th= e > client in the token response. > > > > This means that the AS may leak potentially sensitive information to th= e > client in a new place. Before this was only possible in the ID Token or > UserInfo or if the AS returned a JWT as an access token which the client > popped open (even though it shouldn't). > > > > I understand that the spec considers this an option for the AS to enric= h > or not. I think the enrichment is good and necessary, but with the > side-effect of it ending up in the token response it becomes an issue. > > > > Is the token response a mirror of the authorization_details claim in th= e > corresponding access token, or can it be a masked version? > > > > Perhaps the security considerations section should be updated with a > statement with regards to the fact that the client may see claim data onl= y > intended for the RS? > > > > Regards > > Jacob Ideskog > > > > > > > > -- > > Jacob Ideskog > > CTO > > Curity AB > > ------------------------------------------------------------------- > > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden > > M: +46 70-2233664 > > jacob@curity.io > > curity.io< > https://www.google.com/url?q=3Dhttp://curity.io&source=3Dgmail-imap&ust= =3D1631322760000000&usg=3DAOvVaw0O7NO5RiGVK6v1SxLCSz4k > > > > ------------------------------------------------------------------- > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oaut= h&source=3Dgmail-imap&ust=3D1631322760000000&usg=3DAOvVaw2Fa1GyOiE6a7mRCghw= MI5J > --=20 Jacob Ideskog CTO Curity AB ------------------------------------------------------------------- Sankt G=C3=B6ransgatan 66, Stockholm, Sweden M: +46 70-2233664 j acob@curity.io curity.io ------------------------------------------------------------------- --000000000000da5e4705cb4eefb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, privacy considerations could be more explicit ab= out this. It should probably explicitly mention the token response and the = Client.

I also suggest clarifying in 7 or 7.1 = that the token response MAY be less explicit or even different than the aut= horization details issued in the tokens.

This is n= ot simple, since it may lead the Client to think it has more (or less) acce= ss than it actually does, but since the intended audience of the authorized= data is the RS it should be ok.
A scenario I see is that the cli= ent requests Account access based on pseudonyms or names of the accounts (&= quot;accounts" : ["foo", "bar"]) . The AS replaces= these with the actual account numbers ("accounts" : ["123-1= 23", "234-BCD"]) so the RS doesn't have
to dea= l with those translations. So: in the token response the pseudonyms are sti= ll used, but in the issued token the explicit account values are used.
<= /div>

Suggestion for=C2=A0 section 7:
&quo= t;The AS MAY omit, mask or hide values in the authorization_details to the = Client in the Token Response if these are deemed sensitive and of no intend= ed use for the Client."

Something in that= direction would make it more clear that it is allowed to do so, and that t= he Token Response doesn't prevent the issued token from containing sens= itive data.

/Jacob


Den= l=C3=B6r 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt <torsten@lodderstedt.net>:
The AS intentionally shares t= he list of accounts in the mentioned example with the client. The assumptio= n is the client asks for access to some accounts and the user decides which= accounts to grant the client access to. This means the AS is authorized by= the user to share this data.

The privacy considerations section already has text about sharing data with= resource servers. I suggest to add some text re data sharing with clients.=

Would that work for you?

> Am 04.09.2021 um 03:12 schrieb Justin Richer <jricher@mit.edu>:
>
> =EF=BB=BFThis is a fair point... The privacy and security consideratio= ns talk about this a bit as I recall, but likely need to in more depth and = specificity. This is an intentional message channel to the client from the = AS, but if the AS is blindly sending all information it might be saying mor= e than it means to say to an entity that doesn't need that detail to fu= nction. Scopes have similar issues, but this structure adds more opportunit= ies for mistakes just due to the possible increased complexity.
>
> -Justin
> ________________________________________
> From: OAuth [oauth-bounces@ietf.org] on behalf of Jacob Ideskog [jacob.ideskog@curity.io] > Sent: Friday, September 3, 2021 10:42 AM
> To: oauth
> Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in dra= ft-ietf-oauth-rar-05
>
> Hi all,
>
> I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05= that describes the token response.
>
> The authorization_details values could be sensitive in their nature. T= he example in section 7.1 highlights this nicely. The accounts array is emp= ty when the client requests it, but is enriched by the AS and returned to t= he client in the token response.
>
> This means that the AS may leak potentially sensitive information to t= he client in a new place. Before this was only possible in the ID Token or = UserInfo or if the AS returned a JWT as an access token which the client po= pped open (even though it shouldn't).
>
> I understand that the spec considers this an option for the AS to enri= ch or not. I think the enrichment is good and necessary, but with the side-= effect of it ending up in the token response it becomes an issue.
>
> Is the token response a mirror of the authorization_details claim in t= he corresponding access token, or can it be a masked version?
>
> Perhaps the security considerations section should be updated with a s= tatement with regards to the fact that the client may see claim data only i= ntended for the RS?
>
> Regards
> Jacob Ideskog
>
>
>
> --
> Jacob Ideskog
> CTO
> Curity AB
> ------------------------------------------------------------------- > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden
> M: +46 70-2233664
> j<mailto:jacob= @twobo.com>acob@= curity.io<mailto:acob@curity.io>
> curi= ty.io<https://www.google.com/ur= l?q=3Dhttp://curity.io&source=3Dgmail-imap&ust=3D1631322760000000&a= mp;usg=3DAOvVaw0O7NO5RiGVK6v1SxLCSz4k>
> ------------------------------------------------------------------- >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https= ://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth&s= ource=3Dgmail-imap&ust=3D1631322760000000&usg=3DAOvVaw2Fa1GyOiE6a7m= RCghwMI5J


--
Jacob Ideskog
CTO
Curity AB
----= -----------------------------= -----------------------------= -----
Sankt G=C3=B6ransgatan 66, Stockholm, Sweden
M:=C2=A0+46 70-2233664jacob@curity.io
------------------------------<= span style=3D"color:rgb(136,136,136)">------------------------------= -------
--000000000000da5e4705cb4eefb5-- From nobody Mon Sep 6 03:50:43 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC733A2B16 for ; Mon, 6 Sep 2021 03:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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=hackmanit.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx8EW1l1_SGj for ; Mon, 6 Sep 2021 03:50:36 -0700 (PDT) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF873A2B14 for ; Mon, 6 Sep 2021 03:50:34 -0700 (PDT) Received: by mail-ej1-x629.google.com with SMTP id n27so12675069eja.5 for ; Mon, 06 Sep 2021 03:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=9MRsSyYAlpFO4TD9g1jU3/Mdqczu2n59P9dLXTY1ZSQ=; b=EvpEvk6lrBXmci8S2kEnCTfNcepJXBU9hG/svarEmknnJc9B3u3AHJPaBf1xGye/I1 fXMX6i2zVDuiTGkYlm9AoVj70lkNXNlYPcJMQcpWNGQUJeDUlnmYN81BupKVDyx5UV/Z reKPFZ44VQqRa8yZGPlXc2PXkBIdm0bp8yWt0= 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; bh=9MRsSyYAlpFO4TD9g1jU3/Mdqczu2n59P9dLXTY1ZSQ=; b=mpJba6YtZUsVp76Wd1/1NVaxE/60EuGLgcOCGXn2f1EbHnn882oMiVLM/Hj4qEA8fW O07fkwsxt4+eiiD8syBK6AqxUka5CisrF/dzb7x0zKLkFsFtjHdrqkbhKa25VUtYFwfA M7tO/mHWnGnKqVZywb7aiiKVlzO+pAu4iUuNMtQO1/9ZB92FfW7lSaph95JRqD6P+G0G CcrpiB1qfH46xFaoHZfy43tF3BJTlBYyiFLIRoxq+jUzvLGg4LlodLvXqRXmkvA/ivIi zg5SnIR4IRf5gXfmm/EIAehDDHyAbRcxyJ5PO2lNOAdHKnLu+RZJZtU3nh+4WA40obq/ j/Zg== X-Gm-Message-State: AOAM532oYIz01uh6PMEq5yv0mop5c0HbV9gRYy8CJNZvW8qnzVH1rHks V0JH6Oa+pf33IUylYZjrgW65ASIfIC4F0A== X-Google-Smtp-Source: ABdhPJzFI9IQgU7iDF+JCmAJWsRh/tewqVqvTWf4JmNawgLRZn0xCvJaigBn8Qi+X63TC0fa91w83w== X-Received: by 2002:a17:907:75d0:: with SMTP id jl16mr12816112ejc.166.1630925431515; Mon, 06 Sep 2021 03:50:31 -0700 (PDT) Received: from [192.168.137.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id n2sm4481000edi.32.2021.09.06.03.50.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Sep 2021 03:50:30 -0700 (PDT) To: Rifaat Shekh-Yusef , oauth References: From: Karsten Meyer zu Selhausen Message-ID: <89921372-8c16-3eeb-406f-f55666088e93@hackmanit.de> Date: Mon, 6 Sep 2021 12:50:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1a1snijkgG89wjRITGybLPtcNs4BkLuCl" Archived-At: Subject: Re: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 10:50:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1a1snijkgG89wjRITGybLPtcNs4BkLuCl Content-Type: multipart/mixed; boundary="pszXq6CTul2mtYh0zWYJ8HWjSPghcZ9s9"; protected-headers="v1" From: Karsten Meyer zu Selhausen To: Rifaat Shekh-Yusef , oauth Message-ID: <89921372-8c16-3eeb-406f-f55666088e93@hackmanit.de> Subject: Re: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification References: In-Reply-To: --pszXq6CTul2mtYh0zWYJ8HWjSPghcZ9s9 Content-Type: multipart/alternative; boundary="------------8B68A878CA4E41C6E37EAE05" Content-Language: en-US This is a multi-part message in MIME format. --------------8B68A878CA4E41C6E37EAE05 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rifaat, thank you for the shepherd's review. Those are valid comments. We will have a second look on this paragraph. Best regards, Karsten On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote: > Hi=C2=A0Karsten, Daniel, > > As the document shepherd, I have reviewed the document and I have the=20 > following comments on=C2=A0draft-ietf-oauth-iss-auth-resp-01 version: > > > Section 2.4, paragraph 3, first sentence: > > "If clients interact with both authorization servers supporting this > =C2=A0 =C2=A0specification and authorization servers not supporting thi= s > =C2=A0 =C2=A0specification, clients SHOULD store the information which > =C2=A0 =C2=A0authorization server supports the "iss" parameter." > > Why is this a SHOULD? > > > "Clients MUST > =C2=A0 =C2=A0reject authorization responses without the "iss" parameter= from > =C2=A0 =C2=A0authorization servers which do support the parameter accor= ding to the > =C2=A0 =C2=A0client's configuration." > > What should the client do when it receives a response with "iss" parame= ter > from an authorization server that did not indicate its support for=20 > this parameter? > > > Section 7 > > RFC6479 should be replaced with *RFC6749* > > > Regards, > =C2=A0 Rifaat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Is your OAuth or OpenID Connect application vulnerable to mix-up attacks?= Find out more on our blog: https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-= against-mix-up-attacks Hackmanit GmbH Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz --------------8B68A878CA4E41C6E37EAE05 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Rifaat,

thank you for the shepherd's review.

Those are valid comments. We will have a second look on this paragraph.<= /font>

Best regards,
Karsten

On 04.09.2021 16:20, Rifaat Shekh-Yuse= f wrote:
Hi=C2=A0Karsten, Daniel,

As the document shepherd, I have reviewed the document and I have the following comments on=C2=A0draft-ietf-oauth-iss-auth-res= p-01 version:


Section 2.4, paragraph 3, first sentence:

"If clients interact with both authorization servers supporting this
=C2=A0 =C2=A0specification and authorization servers not suppor= ting this
=C2=A0 =C2=A0specification, clients SHOULD store the informatio= n which
=C2=A0 =C2=A0authorization server supports the "iss" parameter.= "
=C2=A0 =C2=A0
Why is this a SHOULD?


"Clients MUST
=C2=A0 =C2=A0reject authorization responses without the "iss" p= arameter from
=C2=A0 =C2=A0authorization servers which do support the paramet= er according to the
=C2=A0 =C2=A0client's configuration."
=C2=A0 =C2=A0
What should the client do when it receives a response with "iss" parameter
from an authorization server that did not indicate its support for this parameter?


Section 7

RFC6479 should be replaced with RFC6749


Regards,=C2=A0
=C2=A0 Rifaat=C2=A0=C2=A0

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

--=20
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	htt=
ps://hackmanit.de | IT Security Consulting, Penetration Testing, Secu=
rity Training

Is your OAuth or OpenID Connect application vulnerable to mix-up attacks?=
 Find out more on our blog:
https:=
//www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-agains=
t-mix-up-attacks

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
--------------8B68A878CA4E41C6E37EAE05-- --pszXq6CTul2mtYh0zWYJ8HWjSPghcZ9s9-- --1a1snijkgG89wjRITGybLPtcNs4BkLuCl Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEDtqqxgHePX8hI3D4RTXA59sW8UgFAmE18nYFAwAAAAAACgkQRTXA59sW8UgY lRAAzfSCUZzZ/cAhJcNHRjaO033UqbfLctP+OZdVN2uyrbeO7kmigxTl4KCXmuipZQpYZxfMVAZv Tn4OY62Kgqsyytj4e4qHZn/RBJ10Z/lYfWB0gN+m4tU0ibmUbGP+X2zNY0Dd8WzEg0AtJXx9BonW tTx40RHQeDBo4Y6QnPXMd8QyK/fhMf7zjif34nR+tpRakrjRbiIHgk7B7KneBzHYQiG6nOwrL4CC v1BoaP7+Oh0KTIo4ICWUnLcVpW83YlNerYhJd/M1iB5n5ec8MT/HmNgxrNqpk43FC3bIueY71jrF 42MFxjywI9tf90QGpdjYdPQW0V+Ga7QkKQDbyHbPPnPZIshWAFHy1o+28gqe7cL8cBf44UZhagkL 5MEYc55SaagyFyMQeiu+3AZHIojlMv05bUWdigAOUm2cJBw+fQkFMkX0vY5Tu8ehPUnuJ9z+Gm6H 8bFHlMjZVJeshAaJ5fSDIswXohC5QdJe2nic2ant9xqaMxJrPIv3QT2nmYnhCjUTBEW9B0TF+r3x s01pE4X33hVWo48npp61ZEGIxK/o/bwTUpQFe8ldQ4wQ361+CD6f2HAFa77MUnhvgicW9Vem+Hz7 sM0MLnPtdnMRsyU1Gk4plBhj6qCnsY8fT2F36IK5u1iUtasO9GC8mdzfE2LkRRdpD6DertddgKFO dAM= =wx3p -----END PGP SIGNATURE----- --1a1snijkgG89wjRITGybLPtcNs4BkLuCl-- From nobody Mon Sep 6 07:05:54 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602663A0CA6 for ; Mon, 6 Sep 2021 07:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVqTUcCZWy2d for ; Mon, 6 Sep 2021 07:05:47 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450: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 5913A3A0CA5 for ; Mon, 6 Sep 2021 07:05:47 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id l7-20020a1c2507000000b002e6be5d86b3so5387wml.3 for ; Mon, 06 Sep 2021 07:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4wquJTHDnwDbtMgwJxaGq1n7RyKSQ4O82lthLgjbpHU=; b=I1JZzYylK5G4UYhCtf1y/eK0lGlxdEOR8UwIm8VyN/rhvJ+e4lwOEiAvZaJ0J/ly6z jhXCNmpf7avXNvVfoIi0VTcy8cdjjJZVICmm99WZC0a07gKWc/Jw1Urc1+7pgAm2yh03 ICH3/dxoRKHxAfGVaCQ9v2UcVWhoYK1Wp804GSNa4keKtDV8gbyZ9796TesGb3sDB0Yr i41/qQsF8GnTGrcPMHWn/Uz/dHwWHDT/OYoypH3SvSOhlzcNJwBpDXkUGGKRqy5ewCvx 8hQymKMCqWox1nP4FcqdRz6W+bb4mu1DPMn6popmqUopxJWsroUjToWvFruFPPL+D8Eq 0upg== 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=4wquJTHDnwDbtMgwJxaGq1n7RyKSQ4O82lthLgjbpHU=; b=iIoaL/fGd4uD1D9sMvWGtkfNn9XW/cYk7qHeEb0baNVJVrsWeOu+sCrwQlE+xqrHVi dJb1nHtuJgDyvhYN4c5vxuwM6obJuw25wd88rAk/irYSABCqqsq37E+G+wF3IKYoOQo6 A2ccSorkbjSj3ZTpUo/+hTXsQdw7dP/YWB+LoWwIqKqbEagIBkTGzer5BYZv26eSaYoK t/tJvI7jwOwuxeOGNp3UqqokHBkQDnW7jw2Q0gt8Uh9cDTzbVOOYnoZVa6JVX3deDg8S 68yHW6bqDEN5pAbLD3871UrOnTowNwt4EfcRvrCjdbXyKHwT33scKFBdXa0ZVQzg+Sfe osIA== X-Gm-Message-State: AOAM5323PR/zIgSu1iAw+yTjCwcbb2sRX1ThRQJa6mHg2zseMXQWbqxP GnyywZfW+pc6Ib9HlzqUw6zpUA== X-Google-Smtp-Source: ABdhPJwhOySuyVNbmD0p5Et6kWYh9buHk0tXD6PUiZWFhUW7Bm2MyUJwSHSmysDwlujNAYDuYnMKWA== X-Received: by 2002:a7b:c927:: with SMTP id h7mr11568728wml.154.1630937143865; Mon, 06 Sep 2021 07:05:43 -0700 (PDT) Received: from smtpclient.apple (p200300eb8f273bdbd8e16799bd610f2c.dip0.t-ipconnect.de. [2003:eb:8f27:3bdb:d8e1:6799:bd61:f2c]) by smtp.gmail.com with ESMTPSA id x11sm7539103wmk.21.2021.09.06.07.05.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Sep 2021 07:05:43 -0700 (PDT) From: Torsten Lodderstedt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EB38468A-5B67-46DF-AED0-8848A5E20FE3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 6 Sep 2021 16:05:42 +0200 In-Reply-To: Cc: oauth , Justin Richer To: Jacob Ideskog References: <250c6a12d1ab42a4869a0a9689ad1625@oc11expo18.exchange.mit.edu> <0C5C7579-2979-4B64-8163-BA254B07CFC1@lodderstedt.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 14:05:53 -0000 --Apple-Mail=_EB38468A-5B67-46DF-AED0-8848A5E20FE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jacob,=20 and here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79 = for review.=20 Thanks for the proposed text. I modified it a bit because I think the AS = should only omit data (not mask) and data can be provided even if = considered sensitive as long as there is a reasonable purpose and a = legal basis.=20 best regards, Torsten.=20 > Am 06.09.2021 um 09:52 schrieb Jacob Ideskog = : >=20 > Yes, privacy considerations could be more explicit about this. It = should probably explicitly mention the token response and the Client. >=20 > I also suggest clarifying in 7 or 7.1 that the token response MAY be = less explicit or even different than the authorization details issued in = the tokens. >=20 > This is not simple, since it may lead the Client to think it has more = (or less) access than it actually does, but since the intended audience = of the authorized data is the RS it should be ok. > A scenario I see is that the client requests Account access based on = pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The = AS replaces these with the actual account numbers ("accounts" : = ["123-123", "234-BCD"]) so the RS doesn't have > to deal with those translations. So: in the token response the = pseudonyms are still used, but in the issued token the explicit account = values are used. >=20 > Suggestion for section 7: > "The AS MAY omit, mask or hide values in the authorization_details to = the Client in the Token Response if these are deemed sensitive and of no = intended use for the Client." >=20 > Something in that direction would make it more clear that it is = allowed to do so, and that the Token Response doesn't prevent the issued = token from containing sensitive data. >=20 > /Jacob >=20 >=20 > Den l=C3=B6r 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt = >: > The AS intentionally shares the list of accounts in the mentioned = example with the client. The assumption is the client asks for access to = some accounts and the user decides which accounts to grant the client = access to. This means the AS is authorized by the user to share this = data. >=20 > The privacy considerations section already has text about sharing data = with resource servers. I suggest to add some text re data sharing with = clients. >=20 > Would that work for you? >=20 > > Am 04.09.2021 um 03:12 schrieb Justin Richer >: > >=20 > > =EF=BB=BFThis is a fair point... The privacy and security = considerations talk about this a bit as I recall, but likely need to in = more depth and specificity. This is an intentional message channel to = the client from the AS, but if the AS is blindly sending all information = it might be saying more than it means to say to an entity that doesn't = need that detail to function. Scopes have similar issues, but this = structure adds more opportunities for mistakes just due to the possible = increased complexity.=20 > >=20 > > -Justin > > ________________________________________ > > From: OAuth [oauth-bounces@ietf.org ] = on behalf of Jacob Ideskog [jacob.ideskog@curity.io = ] > > Sent: Friday, September 3, 2021 10:42 AM > > To: oauth > > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in = draft-ietf-oauth-rar-05 > >=20 > > Hi all, > >=20 > > I have a question about section 7.0 and 7.1 in = draft-ietf-oauth-rar-05 that describes the token response. > >=20 > > The authorization_details values could be sensitive in their nature. = The example in section 7.1 highlights this nicely. The accounts array is = empty when the client requests it, but is enriched by the AS and = returned to the client in the token response. > >=20 > > This means that the AS may leak potentially sensitive information to = the client in a new place. Before this was only possible in the ID Token = or UserInfo or if the AS returned a JWT as an access token which the = client popped open (even though it shouldn't). > >=20 > > I understand that the spec considers this an option for the AS to = enrich or not. I think the enrichment is good and necessary, but with = the side-effect of it ending up in the token response it becomes an = issue. > >=20 > > Is the token response a mirror of the authorization_details claim in = the corresponding access token, or can it be a masked version? > >=20 > > Perhaps the security considerations section should be updated with a = statement with regards to the fact that the client may see claim data = only intended for the RS? > >=20 > > Regards > > Jacob Ideskog > >=20 > >=20 > >=20 > > -- > > Jacob Ideskog > > CTO > > Curity AB > > ------------------------------------------------------------------- > > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden > > M: +46 70-2233664 > > j>acob@curity.io = > > > curity.io = > > > ------------------------------------------------------------------- > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1631322760000000&usg=3DAOvVaw2Fa1GyOiE6a7mRCghw= MI5J = >=20 >=20 > --=20 > Jacob Ideskog > CTO > Curity AB > ------------------------------------------------------------------- > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden > M: +46 70-2233664 <> > j acob@curity.io > curity.io = > ------------------------------------------------------------------- --Apple-Mail=_EB38468A-5B67-46DF-AED0-8848A5E20FE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jacob, 

and = here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79 = for review. 

Thanks for the proposed text. I modified it a bit because I = think the AS should only omit data (not mask) and data can be provided = even if considered sensitive as long as there is a reasonable purpose = and a legal basis. 

best regards,
Torsten. 

Am 06.09.2021 um 09:52 schrieb Jacob Ideskog <jacob.ideskog@curity.io>:

Yes, privacy considerations could be more = explicit about this. It should probably explicitly mention the token = response and the Client.

I also suggest clarifying in 7 or 7.1 = that the token response MAY be less explicit or even different than the = authorization details issued in the tokens.

This is not simple, since it may lead = the Client to think it has more (or less) access than it actually does, = but since the intended audience of the authorized data is the RS it = should be ok.
A scenario I see is that the client = requests Account access based on pseudonyms or names of the accounts = ("accounts" : ["foo", "bar"]) . The AS replaces these with the actual = account numbers ("accounts" : ["123-123", "234-BCD"]) so the RS doesn't = have
to deal with those translations. So: in the = token response the pseudonyms are still used, but in the issued token = the explicit account values are used.

Suggestion for  = section 7:
"The AS MAY omit, mask or = hide values in the authorization_details to the Client in the Token = Response if these are deemed sensitive and of no intended use for the = Client."

Something in that direction would make it more clear that it = is allowed to do so, and that the Token Response doesn't prevent the = issued token from containing sensitive data.

/Jacob


Den l=C3=B6r 4 sep. 2021 kl 11:41 skrev Torsten = Lodderstedt <torsten@lodderstedt.net>:
The AS intentionally shares the list = of accounts in the mentioned example with the client. The assumption is = the client asks for access to some accounts and the user decides which = accounts to grant the client access to. This means the AS is authorized = by the user to share this data.

The privacy considerations section already has text about sharing data = with resource servers. I suggest to add some text re data sharing with = clients.

Would that work for you?

> Am 04.09.2021 um 03:12 schrieb Justin Richer <jricher@mit.edu>:
>
> =EF=BB=BFThis is a fair point... The privacy and security = considerations talk about this a bit as I recall, but likely need to in = more depth and specificity. This is an intentional message channel to = the client from the AS, but if the AS is blindly sending all information = it might be saying more than it means to say to an entity that doesn't = need that detail to function. Scopes have similar issues, but this = structure adds more opportunities for mistakes just due to the possible = increased complexity.
>
> -Justin
> ________________________________________
> From: OAuth [oauth-bounces@ietf.org] on behalf of = Jacob Ideskog [jacob.ideskog@curity.io]
> Sent: Friday, September 3, 2021 10:42 AM
> To: oauth
> Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in = draft-ietf-oauth-rar-05
>
> Hi all,
>
> I have a question about section 7.0 and 7.1 in = draft-ietf-oauth-rar-05 that describes the token response.
>
> The authorization_details values could be sensitive in their = nature. The example in section 7.1 highlights this nicely. The accounts = array is empty when the client requests it, but is enriched by the AS = and returned to the client in the token response.
>
> This means that the AS may leak potentially sensitive information = to the client in a new place. Before this was only possible in the ID = Token or UserInfo or if the AS returned a JWT as an access token which = the client popped open (even though it shouldn't).
>
> I understand that the spec considers this an option for the AS to = enrich or not. I think the enrichment is good and necessary, but with = the side-effect of it ending up in the token response it becomes an = issue.
>
> Is the token response a mirror of the authorization_details claim = in the corresponding access token, or can it be a masked version?
>
> Perhaps the security considerations section should be updated with = a statement with regards to the fact that the client may see claim data = only intended for the RS?
>
> Regards
> Jacob Ideskog
>
>
>
> --
> Jacob Ideskog
> CTO
> Curity AB
> = -------------------------------------------------------------------
> Sankt G=C3=B6ransgatan 66, Stockholm, Sweden
> M: +46 70-2233664
> j<mailto:jacob@twobo.com>acob@curity.io<mailto:acob@curity.io>
> curity.io<https://www.google.com/url?q=3Dhttp://curity.io&source=3Dgm= ail-imap&ust=3D1631322760000000&usg=3DAOvVaw0O7NO5RiGVK6v1SxLCSz4k= >
> = -------------------------------------------------------------------
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/oauth&source=3Dgmail-imap&ust=3D1631322760000000&usg=3DA= OvVaw2Fa1GyOiE6a7mRCghwMI5J


--
Jacob Ideskog
CTO
Curity AB
-------------------------------------------------------------------
Sankt G=C3=B6ransgatan 66, Stockholm, Sweden
M: +46 70-2233664
jacob@curity.io
curity.io
-------------------------------------------------------------------
<= /div>

= --Apple-Mail=_EB38468A-5B67-46DF-AED0-8848A5E20FE3-- From nobody Mon Sep 6 07:09:17 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7903A0CC8 for ; Mon, 6 Sep 2021 07:09:15 -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, 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=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l98lNhjEhKgU for ; Mon, 6 Sep 2021 07:09:10 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC9E3A0CC5 for ; Mon, 6 Sep 2021 07:09:10 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id k65so13784473yba.13 for ; Mon, 06 Sep 2021 07:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5TzstSmJ2GYFzLCHfR9cNU4z9E9PVxZTDli9X4Ry2Uk=; b=Pc+9fkPCs+7XeVovrUIdqDCQDGw2ytof+yuttjrfIKRQvHi36+o5J+olrAzDKqw7Ha uKxhtavJ82km/zCY7yIZtzohU2hGSi/DEI6Wrml4U8pAsaKx9yiyiJLdwbT9mmzwOMo7 EwR38f+aVUG6G6qD5uw+xhFF3FVw2LrHGbT4VOlc/klZQMbQnU/7EG6r5OQhjnndz7kj kt1bFSFefISt7UwYFv+xKe747WKfTFdfeMUodkhXkDrP+yxrj89CnHAPfSOKFT99MZFs pLsuqZwlCt33o+wXZWD11ziD6LZoOyoB+xM9BPZNo8RIGR3ZHjhigySLpB76hfkN0z6f RKaA== 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=5TzstSmJ2GYFzLCHfR9cNU4z9E9PVxZTDli9X4Ry2Uk=; b=LAWEq2Mz/+ZVEhPFxNSbvwusVuOE/1gi7DiyxLv4BBhHqHYRg8qu4wh+kUFZawiGJh MhtJYKpyKdQpEpCeTam0PPiZTu6LOKoZUdOyvjE7d9fRK24JaYWbw6DgTem4Id1jvhuo 6iqFclh2GBALHMwJLj7hWCoDeZ88tgyTloRyMTP5ZEC8aHIzGL4WGWEDfbRjWrI95uKY Se/Q6ugEFUPMSI430NtniCbZiY/WPPrNU8Kt9aFAgHRKdz5lrzaeFXjjS6hqWZiEKUzC DieEa1HkhTJCiTqUYrJsFPND1HPJ4LXRAcLP9/J3dkaFYewUADFU6EIl82hlXyq8vl/N PaDw== X-Gm-Message-State: AOAM5302y8VELnNk83htSlHO+mrm4+5POySoVViH+qS/IhStjzJOT97a aAEMvFhw983moZ4PCaxEoRm4JzxFNl1W1ghWZCQJRA== X-Google-Smtp-Source: ABdhPJyfujXOdyEKaJmaPQnRwu/XSuQKbtNmGR6JJakzyf5cHaMENDydv8dSkEkZH3ZjIQWovvcfO6Q0AmYN8Bd58NI= X-Received: by 2002:a25:bc02:: with SMTP id i2mr17254983ybh.98.1630937348204; Mon, 06 Sep 2021 07:09:08 -0700 (PDT) MIME-Version: 1.0 References: <250c6a12d1ab42a4869a0a9689ad1625@oc11expo18.exchange.mit.edu> <0C5C7579-2979-4B64-8163-BA254B07CFC1@lodderstedt.net> In-Reply-To: From: Jacob Ideskog Date: Mon, 6 Sep 2021 16:08:57 +0200 Message-ID: To: Torsten Lodderstedt Cc: oauth , Justin Richer Content-Type: multipart/alternative; boundary="0000000000004a7aa805cb54319e" Archived-At: Subject: Re: [OAUTH-WG] RAR 05 - Token response with sensitive data in draft-ietf-oauth-rar-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 14:09:16 -0000 --0000000000004a7aa805cb54319e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Torsten, that's a good addition, it helps to have that clarified. BR Jacob Den m=C3=A5n 6 sep. 2021 kl 16:05 skrev Torsten Lodderstedt < torsten@lodderstedt.net>: > Hi Jacob, > > and here is the PR https://github.com/oauthstuff/draft-oauth-rar/pull/79 = for > review. > > Thanks for the proposed text. I modified it a bit because I think the AS > should only omit data (not mask) and data can be provided even if > considered sensitive as long as there is a reasonable purpose and a legal > basis. > > best regards, > Torsten. > > Am 06.09.2021 um 09:52 schrieb Jacob Ideskog : > > Yes, privacy considerations could be more explicit about this. It should > probably explicitly mention the token response and the Client. > > I also suggest clarifying in 7 or 7.1 that the token response MAY be less > explicit or even different than the authorization details issued in the > tokens. > > This is not simple, since it may lead the Client to think it has more (or > less) access than it actually does, but since the intended audience of th= e > authorized data is the RS it should be ok. > A scenario I see is that the client requests Account access based on > pseudonyms or names of the accounts ("accounts" : ["foo", "bar"]) . The A= S > replaces these with the actual account numbers ("accounts" : ["123-123", > "234-BCD"]) so the RS doesn't have > to deal with those translations. So: in the token response the pseudonyms > are still used, but in the issued token the explicit account values are > used. > > Suggestion for section 7: > "The AS MAY omit, mask or hide values in the authorization_details to the > Client in the Token Response if these are deemed sensitive and of no > intended use for the Client." > > Something in that direction would make it more clear that it is allowed t= o > do so, and that the Token Response doesn't prevent the issued token from > containing sensitive data. > > /Jacob > > > Den l=C3=B6r 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt < > torsten@lodderstedt.net>: > >> The AS intentionally shares the list of accounts in the mentioned exampl= e >> with the client. The assumption is the client asks for access to some >> accounts and the user decides which accounts to grant the client access = to. >> This means the AS is authorized by the user to share this data. >> >> The privacy considerations section already has text about sharing data >> with resource servers. I suggest to add some text re data sharing with >> clients. >> >> Would that work for you? >> >> > Am 04.09.2021 um 03:12 schrieb Justin Richer : >> > >> > =EF=BB=BFThis is a fair point... The privacy and security consideratio= ns talk >> about this a bit as I recall, but likely need to in more depth and >> specificity. This is an intentional message channel to the client from t= he >> AS, but if the AS is blindly sending all information it might be saying >> more than it means to say to an entity that doesn't need that detail to >> function. Scopes have similar issues, but this structure adds more >> opportunities for mistakes just due to the possible increased complexity= . >> > >> > -Justin >> > ________________________________________ >> > From: OAuth [oauth-bounces@ietf.org] on behalf of Jacob Ideskog [ >> jacob.ideskog@curity.io] >> > Sent: Friday, September 3, 2021 10:42 AM >> > To: oauth >> > Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in >> draft-ietf-oauth-rar-05 >> > >> > Hi all, >> > >> > I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05 >> that describes the token response. >> > >> > The authorization_details values could be sensitive in their nature. >> The example in section 7.1 highlights this nicely. The accounts array is >> empty when the client requests it, but is enriched by the AS and returne= d >> to the client in the token response. >> > >> > This means that the AS may leak potentially sensitive information to >> the client in a new place. Before this was only possible in the ID Token= or >> UserInfo or if the AS returned a JWT as an access token which the client >> popped open (even though it shouldn't). >> > >> > I understand that the spec considers this an option for the AS to >> enrich or not. I think the enrichment is good and necessary, but with th= e >> side-effect of it ending up in the token response it becomes an issue. >> > >> > Is the token response a mirror of the authorization_details claim in >> the corresponding access token, or can it be a masked version? >> > >> > Perhaps the security considerations section should be updated with a >> statement with regards to the fact that the client may see claim data on= ly >> intended for the RS? >> > >> > Regards >> > Jacob Ideskog >> > >> > >> > >> > -- >> > Jacob Ideskog >> > CTO >> > Curity AB >> > ------------------------------------------------------------------- >> > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden >> > M: +46 70-2233664 >> > jacob@curity.io >> > curity.io >> >> < >> https://www.google.com/url?q=3Dhttp://curity.io&source=3Dgmail-imap&ust= =3D1631322760000000&usg=3DAOvVaw0O7NO5RiGVK6v1SxLCSz4k >> >> > >> > ------------------------------------------------------------------- >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > >> https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oau= th&source=3Dgmail-imap&ust=3D1631322760000000&usg=3DAOvVaw2Fa1GyOiE6a7mRCgh= wMI5J >> >> > > > -- > Jacob Ideskog > CTO > Curity AB > ------------------------------------------------------------------- > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden > M: +46 70-2233664 > j acob@curity.io > curity.io > > ------------------------------------------------------------------- > > > --=20 Jacob Ideskog CTO Curity AB ------------------------------------------------------------------- Sankt G=C3=B6ransgatan 66, Stockholm, Sweden M: +46 70-2233664 j acob@curity.io curity.io ------------------------------------------------------------------- --0000000000004a7aa805cb54319e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Torsten, that's a good addition, it hel= ps to have that clarified.

BR
Jacob<= br>

Den m=C3=A5n 6 sep. 2021 kl 16:05 skrev Torsten Lodderstedt <torsten@lodderstedt.net>:
Hi Jacob,=C2=A0

and here is the= PR=C2=A0https://github.com/oauthstuff/draft-oauth-rar/pull/79= =C2=A0for review.=C2=A0

Thanks for the proposed te= xt. I modified it a bit because I think the AS should only omit data (not m= ask) and data can be provided even if considered sensitive as long as there= is a reasonable purpose and a legal basis.=C2=A0

= best regards,
Torsten.=C2=A0

Am 06.09.2021 um 09:52 schrieb Jacob Ideskog <jacob.ideskog@curity.io>:<= /div>
Yes, privacy considerations could be mo= re explicit about this. It should probably explicitly mention the token res= ponse and the Client.

I also suggest clarifyin= g in 7 or 7.1 that the token response MAY be less explicit or even differen= t than the authorization details issued in the tokens.

=
This is not simple, since it may lead the Client to think it has more = (or less) access than it actually does, but since the intended audience of = the authorized data is the RS it should be ok.
A scenario I see i= s that the client requests Account access based on pseudonyms or names of t= he accounts ("accounts" : ["foo", "bar"]) . T= he AS replaces these with the actual account numbers ("accounts" = : ["123-123", "234-BCD"]) so the RS doesn't have
to deal with those translations. So: in the token response the pseu= donyms are still used, but in the issued token the explicit account values = are used.

Suggestion for=C2=A0 section 7:
<= /div>
"The AS MAY omit, mask or hide values in the authorization_d= etails to the Client in the Token Response if these are deemed sensitive an= d of no intended use for the Client."

Som= ething in that direction would make it more clear that it is allowed to do = so, and that the Token Response doesn't prevent the issued token from c= ontaining sensitive data.

/Jacob


Den l=C3=B6r 4 sep. 2021 kl 11:41 skrev Torsten Lodderstedt <= torsten@lodder= stedt.net>:
The AS intentionally shares the list of accounts in the mentioned exampl= e with the client. The assumption is the client asks for access to some acc= ounts and the user decides which accounts to grant the client access to. Th= is means the AS is authorized by the user to share this data.

The privacy considerations section already has text about sharing data with= resource servers. I suggest to add some text re data sharing with clients.=

Would that work for you?

> Am 04.09.2021 um 03:12 schrieb Justin Richer <jricher@mit.edu>:
>
> =EF=BB=BFThis is a fair point... The privacy and security consideratio= ns talk about this a bit as I recall, but likely need to in more depth and = specificity. This is an intentional message channel to the client from the = AS, but if the AS is blindly sending all information it might be saying mor= e than it means to say to an entity that doesn't need that detail to fu= nction. Scopes have similar issues, but this structure adds more opportunit= ies for mistakes just due to the possible increased complexity.
>
> -Justin
> ________________________________________
> From: OAuth [oauth-bounces@ietf.org] on behalf of Jacob Ideskog [jacob.ideskog@curity.io] > Sent: Friday, September 3, 2021 10:42 AM
> To: oauth
> Subject: [OAUTH-WG] RAR 05 - Token response with sensitive data in dra= ft-ietf-oauth-rar-05
>
> Hi all,
>
> I have a question about section 7.0 and 7.1 in draft-ietf-oauth-rar-05= that describes the token response.
>
> The authorization_details values could be sensitive in their nature. T= he example in section 7.1 highlights this nicely. The accounts array is emp= ty when the client requests it, but is enriched by the AS and returned to t= he client in the token response.
>
> This means that the AS may leak potentially sensitive information to t= he client in a new place. Before this was only possible in the ID Token or = UserInfo or if the AS returned a JWT as an access token which the client po= pped open (even though it shouldn't).
>
> I understand that the spec considers this an option for the AS to enri= ch or not. I think the enrichment is good and necessary, but with the side-= effect of it ending up in the token response it becomes an issue.
>
> Is the token response a mirror of the authorization_details claim in t= he corresponding access token, or can it be a masked version?
>
> Perhaps the security considerations section should be updated with a s= tatement with regards to the fact that the client may see claim data only i= ntended for the RS?
>
> Regards
> Jacob Ideskog
>
>
>
> --
> Jacob Ideskog
> CTO
> Curity AB
> ------------------------------------------------------------------- > Sankt G=C3=B6ransgatan 66, Stockholm, Sweden
> M: +46 70-2233664
> j<mailto:jacob= @twobo.com>acob@= curity.io<mailto:acob@curity.io>
> curity.io<https://www.g= oogle.com/url?q=3Dhttp://curity.io&source=3Dgmail-imap&ust=3D163132= 2760000000&usg=3DAOvVaw0O7NO5RiGVK6v1SxLCSz4k>
> ------------------------------------------------------------------- >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.google.com/url?q=3Dhttps://ww= w.ietf.org/mailman/listinfo/oauth&source=3Dgmail-imap&ust=3D1631322= 760000000&usg=3DAOvVaw2Fa1GyOiE6a7mRCghwMI5J


--
Jacob= Ideskog
CTO
Curity AB
----------------------------= -----------------------------= ----------
Sankt G= =C3=B6ransgatan 66, Stockholm, Sweden
M:=C2=A0+46 70-2233664
jacob@curity.io
--------------= -----------------------------= ------------------------



--
<= div>
Jacob Ideskog
CTO
Curity AB
------------------------------<= span style=3D"color:rgb(136,136,136)">------------------------------= -------
Sankt G=C3=B6rans= gatan 66, Stockholm, Sweden
M:=C2=A0+46 70-2233664
jacob@curity.io
-------------------------------------------------------------------
--0000000000004a7aa805cb54319e-- From nobody Mon Sep 6 08:59:26 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E143A13EB for ; Mon, 6 Sep 2021 08:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=cT6qt0yh; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=cT6qt0yh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZAntb4yDSas for ; Mon, 6 Sep 2021 08:59:17 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2072.outbound.protection.outlook.com [40.107.21.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A133A13EC for ; Mon, 6 Sep 2021 08:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ofwV9Xpy0HWIrbPVP+3otpa9TdAfWFnB0rC9lnAdJhE=; b=cT6qt0yhVwzxUAG/utH4y+DjVPtTQaB7Wi51SKx44e8pVudL6uHnBn3caJbdzyxOwAy9ph2GFOGahMzwja7vo8lebUov1oTgZpgAuh+hOgosXhN7WiG4Te+YY59Z1nc5vthJ+C+Dn4PrY3ZqfllVcp3uJvQAr4L3pcjbfM5OsSg= Received: from PR3PR09CA0030.eurprd09.prod.outlook.com (2603:10a6:102:b7::35) by AM6PR08MB4230.eurprd08.prod.outlook.com (2603:10a6:20b:b3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.21; Mon, 6 Sep 2021 15:59:12 +0000 Received: from VE1EUR03FT011.eop-EUR03.prod.protection.outlook.com (2603:10a6:102:b7:cafe::43) by PR3PR09CA0030.outlook.office365.com (2603:10a6:102:b7::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Mon, 6 Sep 2021 15:59:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT011.mail.protection.outlook.com (10.152.18.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.19 via Frontend Transport; Mon, 6 Sep 2021 15:59:10 +0000 Received: ("Tessian outbound 0ec886cb54dd:v105"); Mon, 06 Sep 2021 15:59:10 +0000 X-CR-MTA-TID: 64aa7808 Received: from 6459124289a5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6CC80378-5C88-4D09-A268-66E5DAB42ECC.1; Mon, 06 Sep 2021 15:59:05 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6459124289a5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Sep 2021 15:59:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QS0Qzijqv49nkkMtq70Cw4sIbbeKBAv3M5yo/2GR4REfaNiqYhcdVpqtlYHpKsyywY08mFGNk2p6wace8eD5hveF0DXGgVs925s5CzglkUJMnuCGIADgq/iqOVZzG6i3lZEizvpWBNw3kbRwsZ3Cs++fuzZUo0bEhXCEOlFPHu5QzbZlmtnklOZgaV4HTBXx8xQnLx0OkNVART1BkyiO8uvp6u5Tjjvq9mZeTu3wc742zY+Iybjjz2+TVOk5utc+pj0BSTenV5ogBCLys89MZMCTt8tqW8Jl0U1TL23hL01nsIcOVpL17tkUtMXlRsGLoUL2WIeOaqxun3mRbMG7Ew== 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; bh=ofwV9Xpy0HWIrbPVP+3otpa9TdAfWFnB0rC9lnAdJhE=; b=CrzwXpBBQi4Rnmafm956K7f9+ReGiEhC8WDTqCXTR/hjiCmN0aFaRHGUMS4k0G/wpZelpcS0n8HaEQmvUpzGklRZHJwe5y6NDQIVhzobpX9rocZshzNLUp1kubFKiYaoZx2xlFx0jeVOsM0LnqyBhG0B5CN919hU0UJqx40SerKtJMbIDRJ7qrmXQEZCoQddgeAO/rDzrnjbIHC2B6XcO7sv3dSS9K691dud+n4P/yr8G2gM23GkQ6pCsWrhXCR5sQ4CvgfZo7Oc2ArtrQOVHmyBxPp67f2RcVBDsxVV5YncKKPNjhK0PGIPksYkQy+SyTX3pwqWA/uC77Fj4SgB7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ofwV9Xpy0HWIrbPVP+3otpa9TdAfWFnB0rC9lnAdJhE=; b=cT6qt0yhVwzxUAG/utH4y+DjVPtTQaB7Wi51SKx44e8pVudL6uHnBn3caJbdzyxOwAy9ph2GFOGahMzwja7vo8lebUov1oTgZpgAuh+hOgosXhN7WiG4Te+YY59Z1nc5vthJ+C+Dn4PrY3ZqfllVcp3uJvQAr4L3pcjbfM5OsSg= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB7PR08MB3226.eurprd08.prod.outlook.com (2603:10a6:5:22::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.22; Mon, 6 Sep 2021 15:59:04 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::89bf:bcfa:58b5:64b8]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::89bf:bcfa:58b5:64b8%9]) with mapi id 15.20.4478.025; Mon, 6 Sep 2021 15:59:03 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: No OAuth WG Virtual Office Hours today Thread-Index: AdejOA422P5lv0kmQZSF3R/DD16I/Q== Date: Mon, 6 Sep 2021 15:59:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 5BB99A50A9CA264BAB6003FB3AA3D3E1.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: d8c12324-98ac-46b2-394a-08d9714f4436 x-ms-traffictypediagnostic: DB7PR08MB3226:|AM6PR08MB4230: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 3xx+NssE3gFjnHzozGyp/tyB/VlMyNFwh0g6F0024DMDQJXytDVcAxwWPGvcqFc7xUuh40VJ4MXy+MG9DCWBIlErpyQm0k23WH+42n/rX4mX1FOpRKumkqwEvqbe66UUOCoXYsNSg9kpZNX5EZaRwSTRPWnM2R4IJj4vTM3tSxW0MOEVevVVcV06AsAIRpD2nIt/oSZC36zUaexByDxkuvuJM5nucVvmftQUJYcucUAbkB7R7Wtbu4fXn/yqqFevqdevwEuk6/peze1GMcMWP3jyRqNYm9ctPqoM3f9koYhMgdgCiqNRxqMDEY4rKGABBJS4KELS61A26F6thARrt8zaED7XFYf30ZlfuEXP+1miquAbEKXeUwbGYfVfIrLP1rduNv6NqyFW/ITN2WTBkZe4yywNp4Pcxd+IvAIf2WHNj5kZHJ3rNIH7AESxMk9/NHrzPGZQ9NT+PM/WUStExnl9jLLiEmtmjHwXR9yXX1fs5Zpvfl2ZEkWkaxrtSmP1Gh7v09dt2ngzX5sBfX7LgVi+0MNjWxD5/LUIaI96d/x/mBT5ZFyalRLgkuFy3du82beXjjwcOtN1EER9DwqaPTFP2LmbnlmjmXXLfq3fs1HEbBC3JmOahptme+V6Zg8q2FBUGgoZSAhJfRZSM8hCxCrNtUU+fuhbw+JbCsPLdzq/V+I0kR4J18RHxyArqv+KItg+hJmLyLZCMO3ArfjnWQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(396003)(376002)(39860400002)(346002)(33656002)(5660300002)(55016002)(4744005)(66946007)(66556008)(478600001)(186003)(9686003)(26005)(8676002)(52536014)(8936002)(6916009)(38100700002)(71200400001)(38070700005)(86362001)(83380400001)(6506007)(122000001)(66446008)(64756008)(76116006)(66476007)(2906002)(7696005)(316002); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB591595339FD3766719A33824FAD29DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3226 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT011.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d4109af2-75c3-49a9-7504-08d9714f3f9b X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wcLrCYPLe9Ngm6QQQUfc+eNpG99b5a+2c3CyIqcY1D/K/ok7T5Oy+3iO2nBijKZ0lZAhoyiYQHq8MPaiVBOnWyKeWr+/p2sh7QYaw95LXE7oVBEwHEvhP8K/g+ABv+qd3dROwamD1hFGkZJtuLVTUdh/6MX60VM0PgjNEaGf7+xcwFdOLmLtxtPdy1ttT5yCT+zqxggVsB4+0BlYW441CsAfJgw3AmNv/hNEfoJQOnUZxxZXP5bPLrRcZGVh/jRpEIdBnsUXd8tLtmndZeSjIGgFsFgc7Ob6FBzXaUNxnER3r8yjaxftFyxRLNot4UDmWdgneBWwGiNr6PsdsUzM4tLrhoAW+Ny5aWMTxGgCGQxeiNEgByc27hQOniR4WA3FlyyYiX8mrxr4CPPTxCowzWjy+ey/4aRyHZxBr1ChJEhcpVQ9bcsB/WsOKt5dJbl457B7Od89NUgOPYKkW9HTYtuHLrJhR4pAzzUj4yfLqKo3j3L8AJC9LgA4uiLHzuRSxOE1GZz4+nxsA3F0gwzoLVor0jVWWgKS1eFRyDmRcFtDKXbECoGrJU5qnUfGEMPnJ324rqHkN3zIKO4m6aJXtkhd6FWtxD5dK5CnuscGM0IyjVkZql5cFJ+c218nNol03RhdLyD0F1DePYXaod6SIkTVnVxOKZQdX5v1xNBcxIEGIrv4l9q5Wqn3RUigkzs7wT1aN54oWhkQsKO71c/LzQ== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(36840700001)(46966006)(6506007)(7696005)(33656002)(6916009)(83380400001)(36860700001)(336012)(81166007)(356005)(8936002)(186003)(8676002)(26005)(2906002)(52536014)(5660300002)(316002)(86362001)(9686003)(47076005)(70206006)(70586007)(508600001)(55016002)(82310400003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Sep 2021 15:59:10.9366 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d8c12324-98ac-46b2-394a-08d9714f4436 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT011.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4230 Archived-At: Subject: [OAUTH-WG] No OAuth WG Virtual Office Hours today X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 15:59:24 -0000 --_000_DBBPR08MB591595339FD3766719A33824FAD29DBBPR08MB5915eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Due to the holiday in the US and in Canada we are skipping the call today. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DBBPR08MB591595339FD3766719A33824FAD29DBBPR08MB5915eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Due to the holiday in the US and in Canada we are sk= ipping the call today.

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DBBPR08MB591595339FD3766719A33824FAD29DBBPR08MB5915eurp_-- From nobody Mon Sep 6 11:28:56 2021 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 0690A3A1991; Mon, 6 Sep 2021 11:28:44 -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: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Rifaat Shekh-Yusef , The IESG , draft-ietf-oauth-jwt-introspection-response@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org, rfc-editor@rfc-editor.org, rifaat.s.ietf@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <163095292394.10816.17903407107606335812@ietfa.amsl.com> Date: Mon, 06 Sep 2021 11:28:43 -0700 Archived-At: Subject: [OAUTH-WG] Protocol Action: 'JWT Response for OAuth Token Introspection' to Proposed Standard (draft-ietf-oauth-jwt-introspection-response-12.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, 06 Sep 2021 18:28:44 -0000 The IESG has approved the following document: - 'JWT Response for OAuth Token Introspection' (draft-ietf-oauth-jwt-introspection-response-12.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-jwt-introspection-response/ Technical Summary This draft proposes an additional JSON Web Token (JWT) based response for OAuth 2.0 Token Introspection. Working Group Summary The document received many reviews and feedback from multiple WG members on the mailing list and during the WG meetings. During initial IESG review, it received a DISCUSS that required a change of sufficient scope that that it was returned to the WG. The WG addressed the issue and the document again went through WGLC and IETF LC. The proposed change moves the data of the introspected token into a top-level JWT claim to allow for the separation of the carrier JWT claims from the actual token introspection response claims. Document Quality: The document has been implemented by the following: * node.js OSS oidc-provider implements the document in full behind an optional feature toggle https://github.com/panva/node-oidc-provider/blob/master/docs/README.md#featuresjwtintrospection * connect2id has an implementation: https://connect2id.com/products/server/docs/api/token-introspection * ForgeRock: https://github.com/ForgeRock/PSD2-Accelerators/tree/yes.com/openig/yes-openig-signed-introspect-filter Personnel: The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Roman Danyliw. From nobody Wed Sep 8 09:44:46 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2033A2EA2 for ; Wed, 8 Sep 2021 09:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 n2EGA85tpN9x for ; Wed, 8 Sep 2021 09:44:41 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41273A2EA0 for ; Wed, 8 Sep 2021 09:44:40 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id t19so5599001lfe.13 for ; Wed, 08 Sep 2021 09:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b+xuboOSv1Rp9H3UAuLOdylmKJN66ag6RUrUy2OzJNY=; b=ZeaBftRwWL1Th7SDB8e7sPMmiNTwm+NVShkwzcTup9eBVN0HV5VSJLA8Grx/bCqqJX YHQg1EppLZkkc4XJIL9iX+ieaDQiVW7Q89YwcYp14vEtErZ2pV/Lt4FKro7OVwVU3hyI oLPYucx9EYSRMBXZ0DJr4pm92VzwrSzT0jtDrmw5cIJcSQbGRjSDHWGM6Okc37DyLh+y xAx5N2R57F7UDpyqzJKVuw6Mc6Yb90ccdZGC/fPUz9LaAqp/yiHfhWlhoVwp17zncGvb Xq0/JoqnpzwX2e4isNVxrcFWFR2+KJfaTDToaq81NcinbWX9osRYNYP5pP/aMl+dOY85 H+rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b+xuboOSv1Rp9H3UAuLOdylmKJN66ag6RUrUy2OzJNY=; b=URaNjw65SJJjv0V8CvJCkYCw9H1k2bf2jDHu4t65RpKPzUHXkNl3Mgf0aeiaTB38gs 2mqDifst4P1g0MCdR3P8g4qxjge0Df7C8SmAha/7+28VjwYBBYaGhzpqhOc/xEbe3DGo /0gMyzzERJV6L7uYnKjKuQ2DLfB6seOiXKb8s42jO216uxmv9/xcKzoY3Mnu/tvwq5lx u8zQexI9vaYTajEoEryFkbF1uzgblvN6VsbUoWIWAw8AvOoLxU0gvsvEij/FpYPSr+nx ljLbRBDHaSU25oUf9QNvorq5AuAc/UNU4OBQU6BbiogQfRVtUqrBT3DAjkSoz4qLjWR8 2hww== X-Gm-Message-State: AOAM533/pgasVi7E07jPmHwjXa5P9DrPbP+/AiFS/K98yGqIvQ3J7Srs bMT6xyPNKVguHZn0Nl761ByA9+27JVUBcKzqngZ/HFv4xU8= X-Google-Smtp-Source: ABdhPJz9rFojbuPfbhrPGy/Fubh5QvU/wpc+1l26V2ybkS9B7eTcFVw1sit+OwumPRKRa3yxlJFdo9laaH+1x3DzQAw= X-Received: by 2002:a05:6512:2307:: with SMTP id o7mr3393369lfu.352.1631119477212; Wed, 08 Sep 2021 09:44:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Wed, 8 Sep 2021 12:44:25 -0400 Message-ID: To: oauth Cc: Karsten Meyer zu Selhausen , Daniel Fett Content-Type: multipart/alternative; boundary="000000000000068d2b05cb7e9928" Archived-At: Subject: Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 16:44:44 -0000 --000000000000068d2b05cb7e9928 Content-Type: text/plain; charset="UTF-8" Karsten, Daniel, Any update on this? Regards, Rifaat On Sat, Sep 4, 2021 at 10:30 AM Rifaat Shekh-Yusef wrote: > Authors, > > As part of the shepherd write-up, all authors of the document must confirm > that any and all appropriate IPR disclosures required for full conformance > with the provisions of BCP 78 and BCP 79 have already been filed. > > Please, reply to this email on the mailing list and indicate if you are > aware of any IPRs associated with this document. > > Regards, > Rifaat > > --000000000000068d2b05cb7e9928 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Karsten, Daniel,

Any update on this= ?

Regards,
=C2=A0Rifaat


On Sat, Sep 4, 2021 at 10:30 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
=
Authors,=

As part of the shepherd write-up, all authors of the do= cument must confirm that any and all appropriate IPR disclosures required f= or full conformance with the provisions of BCP 78 and BCP 79 have already b= een filed.

Please, reply to this email on the mail= ing list and indicate if you are aware of any IPRs associated with this doc= ument.

Regards,
=C2=A0Rifaat
<= br>
--000000000000068d2b05cb7e9928-- From nobody Wed Sep 8 14:06:24 2021 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 07E213A387F; Wed, 8 Sep 2021 14:06:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <163113518295.29022.11476429616637829688@ietfa.amsl.com> Date: Wed, 08 Sep 2021 14:06:23 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-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, 08 Sep 2021 21:06:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : The OAuth 2.1 Authorization Framework Authors : Dick Hardt Aaron Parecki Torsten Lodderstedt Filename : draft-ietf-oauth-v2-1-03.txt Pages : 86 Date : 2021-09-08 Abstract: The OAuth 2.1 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 8 14:16:33 2021 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 CD96A3A03EA; Wed, 8 Sep 2021 14:16:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: oauth-chairs@ietf.org, oauth@ietf.org, rdd@cert.org, rifaat.s.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163113578081.841.17679633728705078342@ietfa.amsl.com> Date: Wed, 08 Sep 2021 14:16:20 -0700 Archived-At: Subject: [OAUTH-WG] oauth - Not having a session at IETF 112 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, 08 Sep 2021 21:16:31 -0000 Rifaat Shekh-Yusef, a chair of the oauth working group, indicated that the oauth working group does not plan to hold a session at IETF 112. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Sep 8 14:23:30 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A1B3A0112 for ; Wed, 8 Sep 2021 14:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avzRdurtXaGe for ; Wed, 8 Sep 2021 14:23:24 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0333A0147 for ; Wed, 8 Sep 2021 14:23:23 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id c79so4845769oib.11 for ; Wed, 08 Sep 2021 14:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oPTaBXOl22lccrwUpVzeGRHCo1XNKk8lVwfaMk3s8L0=; b=m6STb5gT1I/QlnE8WWaINxAuor0f7wbfJV3KHsrWP/4FM+vaDAgy6lU8ctTXTcNvtH bFuemSqh5TpWzFTdqfUmsZhqZDSmzYje7cULcfAAuaVqSMjNH7+dY8F6lD2nBqyH6Iut Q6laiB3PW25tNcEz3464fZe++VqdApkX2QJv7p2MHEq2hvqV3AnVtuQUR2IEHQVWvzqW +/BP0Z/O7tlthHEPsUyBObb7epbQNBdi5I8R25sWnH5bc929nrOVsPbpoZoTX3diScOa Ci1BR2fwXU9PP8ZCOhuS0LhhdVD+/uRwe2HZzZn9toK/K/gkxK+1QXPw66gTL23BZhpr 1c4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oPTaBXOl22lccrwUpVzeGRHCo1XNKk8lVwfaMk3s8L0=; b=AyOTSQSlE7Z/nOqOjfF7aahQog55qN+shMNN58W7JBiOih1/oWDMsMQRTggkfsCdSY zKCxwrpvNo7mWq5LN+1NNIf/fMCCbXE29fMSrKH/qe747EgF5knqRE7IbS1zdGTQWXbB d2hDc1iRYxeqAIVgV1G4UyTxJ2s/y9S4+ou4rKRuUw0vSCSzV9djb8RioXMXkhtoTS9q g0KnFw4tf7x43DjrwOlnNY6Z9/ja7806nkc2C4/eCxYwQqO1bQcix5dMZeld2meIrQQc vEXVGTStfEWq25FYQgZu7mdOWtkByjtDNijbbN9px5zc1dgoyu8iDsHcisnv98DaTS/K p4zQ== X-Gm-Message-State: AOAM533SsEbM/e3UGy5Db9bwpWdPTbCFjOI49sCg2R+ReeF1ml4oRFNK YySmdnITMrgW1JPTXA+CR2tQk+Dc1r8xRg== X-Google-Smtp-Source: ABdhPJzTsuMGpbxCl0gJRWkzql5t+7plNG+u5rSl4fV4kW+1KVyllHWGnKoTh0iFYwBEP6tCrtcb/g== X-Received: by 2002:aca:f189:: with SMTP id p131mr4080365oih.128.1631136201348; Wed, 08 Sep 2021 14:23:21 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com. [209.85.210.42]) by smtp.gmail.com with ESMTPSA id be5sm54076oib.10.2021.09.08.14.23.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Sep 2021 14:23:20 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id c19-20020a9d6153000000b0051829acbfc7so4794719otk.9 for ; Wed, 08 Sep 2021 14:23:20 -0700 (PDT) X-Received: by 2002:a9d:7107:: with SMTP id n7mr167882otj.177.1631136200419; Wed, 08 Sep 2021 14:23:20 -0700 (PDT) MIME-Version: 1.0 References: <163113518295.29022.11476429616637829688@ietfa.amsl.com> In-Reply-To: <163113518295.29022.11476429616637829688@ietfa.amsl.com> From: Aaron Parecki Date: Wed, 8 Sep 2021 14:23:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary="000000000000ce703c05cb827d51" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-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, 08 Sep 2021 21:23:29 -0000 --000000000000ce703c05cb827d51 Content-Type: text/plain; charset="UTF-8" Hi all, The editors have published a new draft of OAuth 2.1. https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-03.html Huge thanks to Vittorio Bertocci and Justin Richer for their previous reviews of the draft, a large portion of the changes in this version are based on their feedback. Here is a high level summary of the changes from the previous draft: * The major change is a refactoring to collect all the grant types under the same top-level header in section 4: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-03.html#name-grant-types * Better split normative and security consideration text into the appropriate places, both moving text that was really security considerations out of the main part of the document, as well as pulling normative requirements from the security considerations sections into the appropriate part of the main document * Incorporated many of the published errata on RFC6749 * Updated references to various RFCs * Quite a lot of editorial clarifications throughout the document We will continue to make progress on incorporating the suggestions from previous reviews, but in the mean time, this was a significant structural change that warranted publishing a new draft ahead of the upcoming interim meetings. As always, feedback is greatly appreciated! Thanks! --- Aaron Parecki https://aaronparecki.com https://oauth2simplified.com On Wed, Sep 8, 2021 at 2:06 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 : The OAuth 2.1 Authorization Framework > Authors : Dick Hardt > Aaron Parecki > Torsten Lodderstedt > Filename : draft-ietf-oauth-v2-1-03.txt > Pages : 86 > Date : 2021-09-08 > > Abstract: > The OAuth 2.1 authorization framework enables a third-party > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and an authorization service, or by > allowing the third-party application to obtain access on its own > behalf. This specification replaces and obsoletes the OAuth 2.0 > Authorization Framework described in RFC 6749. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-03.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-1-03 > > > 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 > --000000000000ce703c05cb827d51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The editors ha= ve published a new draft of OAuth 2.1.=C2=A0


<= /div>
Huge thanks to Vittorio Bertocci and Justin Richer for their prev= ious reviews of the draft, a large portion of the changes in this version a= re based on their feedback.

Here is a high level s= ummary of the changes from the previous draft:

* The major change is a refactoring to collect all the grant types under t= he same top-level header in section 4:=C2=A0https://www.iet= f.org/archive/id/draft-ietf-oauth-v2-1-03.html#name-grant-types
* Better split normative and security consideration text into the approp= riate places, both moving text that was really security considerations out = of the main part of the document, as well as pulling normative requirements= from the security considerations sections into the appropriate=C2=A0part o= f the main document
* Incorporated many of the published errata o= n RFC6749
* Updated references to various RFCs
* Quite = a lot of editorial clarifications throughout the document

We will continue to make progress on incorporating the suggestions = from previous reviews, but in the mean time, this was a significant structu= ral change that warranted publishing a new draft ahead of the upcoming inte= rim meetings. As always, feedback is greatly appreciated!

Thanks!




On Wed, Sep 8, 2021 at 2:06 PM <internet-drafts@ietf.org> wro= te:

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:= The OAuth 2.1 Authorization Framework
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dick= Hardt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Aaron Parecki
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Torsten Lodderstedt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-v2-1-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 86
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2021-09-08

Abstract:
=C2=A0 =C2=A0The OAuth 2.1 authorization framework enables a third-party =C2=A0 =C2=A0application to obtain limited access to an HTTP service, eithe= r on
=C2=A0 =C2=A0behalf of a resource owner by orchestrating an approval intera= ction
=C2=A0 =C2=A0between the resource owner and an authorization service, or by=
=C2=A0 =C2=A0allowing the third-party application to obtain access on its o= wn
=C2=A0 =C2=A0behalf.=C2=A0 This specification replaces and obsoletes the OA= uth 2.0
=C2=A0 =C2=A0Authorization Framework described in RFC 6749.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-o= auth-v2-1/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-i= etf-oauth-v2-1-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-oauth-v2-1-03


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
--000000000000ce703c05cb827d51-- From nobody Thu Sep 9 04:34:11 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C933A0CF5 for ; Thu, 9 Sep 2021 04:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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=hackmanit.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWlWeHUv5wGR for ; Thu, 9 Sep 2021 04:34:04 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450: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 29FE63A0FCC for ; Thu, 9 Sep 2021 04:34:02 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id eb14so2191346edb.8 for ; Thu, 09 Sep 2021 04:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackmanit.de; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=l21TIJ7Lb9rM8Q1fFx9Gn30qAkrSK6j7HXMKzr3NAsI=; b=iF2eOz8tqRH6LhR9ifp8UCRRAkK/yeAa1kW+1QWRUEcGXCeq/kWec4OmkdXhrxl0Kh yQXrqbBDlCHOSdGshLgJJdzDB2/nunFZE/qTAi/7gJOzVDvxycofAAlPIQnGk3eWJ8XY ZX9pCPifXlK6Jg9qoKAv8W2ovoe7/kqSj9vYQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=l21TIJ7Lb9rM8Q1fFx9Gn30qAkrSK6j7HXMKzr3NAsI=; b=lqdp7vVkERsgfTUNzm9b1IQzTxzEAHP5J/5r9banCExQj8YqUJ3qZE/b1De9x4TeFb h2+D6V1J6jpgfZjC6i6dRfJhXmqh9hIo2hIbAMKClgoHHcG4T7fBNhiYWQoV2W8/VtQK 7qkLjxvvHAqkxLbqSUcmPiAEPNcafJqE7WNYi13LuuPExuw/bGWoSMB5TyVq1k3gHk0x PDQ0kNK9nagFBPZngkU2fz+vL1rFNYCwZmI+4l/MplKXO/R4rtrNMIdo+344OL7t1zT2 A/9ebxHDamOGuZRu39cR4sqMPgKyVuZnPbXfWR54dMXnuXbCzWLoRa0pye9wI5HGtgVN q5uw== X-Gm-Message-State: AOAM531nwTIsBq+xKPJ6UBqimbWZz5J39m/qciLpfHLAxIi9sZek1ka3 os7IdU0ktpxv1chSr8m7P/LmQw== X-Google-Smtp-Source: ABdhPJwr52EUsgwKID4Ss7hMede1/87kUHG1gkUlXiaBrgC/N+Y7DxbdL4DbLEsYF1I1suQ8b0CFCA== X-Received: by 2002:a05:6402:6d2:: with SMTP id n18mr2637876edy.333.1631187240115; Thu, 09 Sep 2021 04:34:00 -0700 (PDT) Received: from [192.168.137.22] (b2b-37-24-87-133.unitymedia.biz. [37.24.87.133]) by smtp.gmail.com with ESMTPSA id t12sm789753ejc.63.2021.09.09.04.33.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Sep 2021 04:33:59 -0700 (PDT) To: Rifaat Shekh-Yusef , oauth References: From: Karsten Meyer zu Selhausen Message-ID: <1546b25e-4cac-55dd-e0d5-4d742bff832b@hackmanit.de> Date: Thu, 9 Sep 2021 13:33:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="At598LxqJ2SKLHoLA3ZzKAyWqgTFoxGTc" Archived-At: Subject: Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2021 11:34:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --At598LxqJ2SKLHoLA3ZzKAyWqgTFoxGTc Content-Type: multipart/mixed; boundary="u6HYedxhj7SbMInFHW8W3XE68y2s7qiTW"; protected-headers="v1" From: Karsten Meyer zu Selhausen To: Rifaat Shekh-Yusef , oauth Cc: Daniel Fett Message-ID: <1546b25e-4cac-55dd-e0d5-4d742bff832b@hackmanit.de> Subject: Re: IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification References: In-Reply-To: --u6HYedxhj7SbMInFHW8W3XE68y2s7qiTW Content-Type: multipart/alternative; boundary="------------688A84C98F45380BF8D35748" Content-Language: en-US This is a multi-part message in MIME format. --------------688A84C98F45380BF8D35748 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rifaat, sorry for the delay. I am not aware of any IPR related to the OAuth 2.0 Authorization Server=20 Issuer Identification draft. Best regards, Karsten On 08.09.2021 18:44, Rifaat Shekh-Yusef wrote: > Karsten, Daniel, > > Any update on this? > > Regards, > =C2=A0Rifaat > > > On Sat, Sep 4, 2021 at 10:30 AM Rifaat Shekh-Yusef=20 > > wrote: > > Authors, > > As part of the shepherd write-up, all authors of the document must > confirm that any and all appropriate IPR disclosures required for > full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. > > Please, reply to this email on the mailing list and indicate if > you are aware of any IPRs associated with this document. > > Regards, > =C2=A0Rifaat > --=20 Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training Is your OAuth or OpenID Connect application vulnerable to mix-up attacks?= Find out more on our blog: https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-= against-mix-up-attacks Hackmanit GmbH Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz --------------688A84C98F45380BF8D35748 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Rifaat,

sorry for the delay.<= /font>

I am not aware of any= IPR related to the OAuth 2.0 Authorization Server Issuer Identification draft.

Best regards,
Karsten

On 08.09.2021 18:44, Rifaat Shekh-Yuse= f wrote:
Karsten, Daniel,

Any update on this?

Regards,
=C2=A0Rifaat


On Sat, Sep 4, 2021 at 10:3= 0 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
=
Authors,

As part of the shepherd write-up, all authors of the document must confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Please, reply to this email on the mailing list and indicate if you are aware of any IPRs associated with this document.

Regards,
=C2=A0Rifaat

--=20
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	htt=
ps://hackmanit.de | IT Security Consulting, Penetration Testing, Secu=
rity Training

Is your OAuth or OpenID Connect application vulnerable to mix-up attacks?=
 Find out more on our blog:
https:=
//www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-agains=
t-mix-up-attacks

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S=
omorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
--------------688A84C98F45380BF8D35748-- --u6HYedxhj7SbMInFHW8W3XE68y2s7qiTW-- --At598LxqJ2SKLHoLA3ZzKAyWqgTFoxGTc Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEDtqqxgHePX8hI3D4RTXA59sW8UgFAmE58SYFAwAAAAAACgkQRTXA59sW8Uib HhAAsiAet8fPN8gohBU94rq3Es8/C9MF2iVUl5RQG43tzH/2PPWGrn7c+OxB4MON98xB4KVzblzK R3H9NsQG+A88zafK/99yGEzA69sp9+mh2/FTC+bgmE6OGeoGS3euUkWbHsMIXbMOY06hihD0e8Mc wLm4eBop0SwfEUnucOi4+vYTle7eAf1bEoW7mQwzxvAe0Uu6ei4YZDCN/oTIsVLASDceyZjPdgme rbiSiAUahASZf3iiWd3ANXy3tqBmG64YMvptTCGfVjWwhtmxv5owA8q3ODYd0PHFPYBl+WhxUU0F l1mCNBKieuKguPgDXZJo6Bb/G+ryDM7Pg8jyF8yw9uQcKXqJJh9R3f5js+2Ftj9zAn/n05/dGq5N 8z37xuY34typzCkF/ZDKandXf4hbkIs3+Y8oVbI80ynv0JZwveUlsX2skwtnZwpYbRf4EoApYhfl 9Unds2i7C91aVpgfeIcnhSxlGDxuTs8oEO17YiB6w4hu1EdpsRbEw3utg+ZxqzccYk+K8AUMfXbJ rjdCT+ypqK1yLNM75NLtAhaBmrV5E2SH6CP4FIBgqNjX1LhrY/+IKIgK0G2+6E3Shg8BuQMZTxq3 XwsNzJlOBU1CjXQ4HJtWL+tm5Le+g0y0w0yuUH0KuyWRHrxmEP9235+ecrDYZ1WTF1XH5u1dm9rT 9oE= =zSxO -----END PGP SIGNATURE----- --At598LxqJ2SKLHoLA3ZzKAyWqgTFoxGTc-- From nobody Sat Sep 11 04:08:12 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63CC3A0ECC for ; Sat, 11 Sep 2021 04:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9MVSHgxkFFb for ; Sat, 11 Sep 2021 04:08:03 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADA53A0ECB for ; Sat, 11 Sep 2021 04:08:02 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id C3B681286D; Sat, 11 Sep 2021 11:07:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1631358476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8S6EbwSnb2t3VlinxLs24ukD678fC5fud39nsG5AVkM=; b=PS9klvW1AMjD0jiRCiWM4NWSqiSSrea8efAfUmwxJMcCcZHa9CvXwXKSPEjQK1oxKnAQbP ae2hMn6QYlNfmbkS29kcw2/J6EKez1DcSSD2ac01aVmefBJv+UxIjZkPzjPYpsPMfL32if A76r4FltvoYLLxC1GQQUa/Wl7QYJ4QY= To: Rifaat Shekh-Yusef , oauth Cc: Karsten Meyer zu Selhausen References: From: Daniel Fett Message-ID: <804c44b0-afc3-49c5-943f-add0f3aa9762@danielfett.de> Date: Sat, 11 Sep 2021 13:07:54 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E7A9DAA90C45177FC571C7ED" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1631358476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8S6EbwSnb2t3VlinxLs24ukD678fC5fud39nsG5AVkM=; b=WuH2F0UfSuMsRIvxdTzhplLhcR7IZjqXOPAERTsLEzPbXIh5tls7u9Wbt7ixeR6geuKl+D dP6jOBxxdE8gJS+WJHL/4nRJaM/Sb6aLTURbDx15fdRDNlJJ9F1dmkDzWmJY8jYq8wSwUN dp78K/8MyKtUnXRBF5I9BYIFswAI+W0= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1631358476; a=rsa-sha256; cv=none; b=MSBAMyMm45aqYjyfEFi9KX181RJj3DsbOPXbeObQSCE2u+V709TaFs5woQm+J1es3yeWmk auWQVWzptv8XYUMW2F0wqdNYgLytcMAIlLNo8W1CD2uhkvPjNzmkn/sES5H433cWssB9Zp nZoW57ql5DzT9aYjC2kJ/tZ88wbaepc= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: -- Archived-At: Subject: Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-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, 11 Sep 2021 11:08:10 -0000 This is a multi-part message in MIME format. --------------E7A9DAA90C45177FC571C7ED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Rifaat, not sure why, but I totally missed that first email. Thanks for the reminder! I am not aware of any IPR related to the OAuth 2.0 Authorization Server Issuer Identification draft. -Daniel Am 08.09.21 um 18:44 schrieb Rifaat Shekh-Yusef: > Karsten, Daniel, > > Any update on this? > > Regards, >  Rifaat > > > On Sat, Sep 4, 2021 at 10:30 AM Rifaat Shekh-Yusef > > wrote: > > Authors, > > As part of the shepherd write-up, all authors of the document must > confirm that any and all appropriate IPR disclosures required for > full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. > > Please, reply to this email on the mailing list and indicate if > you are aware of any IPRs associated with this document. > > Regards, >  Rifaat > -- https://danielfett.de --------------E7A9DAA90C45177FC571C7ED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Rifaat,

not sure why, but I totally missed that first email. Thanks for the reminder!

I am not aware of any IPR related to the OAuth 2.0 Authorization Server Issuer Identification draft.

-Daniel

Am 08.09.21 um 18:44 schrieb Rifaat Shekh-Yusef:
Karsten, Daniel,

Any update on this?

Regards,
 Rifaat


On Sat, Sep 4, 2021 at 10:30 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
Authors,

As part of the shepherd write-up, all authors of the document must confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Please, reply to this email on the mailing list and indicate if you are aware of any IPRs associated with this document.

Regards,
 Rifaat


-- 
https://danielfett.de
--------------E7A9DAA90C45177FC571C7ED-- From nobody Sun Sep 12 08:19:55 2021 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 53E363A0D4A; Sun, 12 Sep 2021 08:19: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: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <163145997727.28449.3480470371140187748@ietfa.amsl.com> Date: Sun, 12 Sep 2021 08:19:37 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-06.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 15:19:38 -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 Rich Authorization Requests Authors : Torsten Lodderstedt Justin Richer Brian Campbell Filename : draft-ietf-oauth-rar-06.txt Pages : 42 Date : 2021-09-12 Abstract: This document specifies a new parameter "authorization_details" that is used to carry fine grained authorization data in the OAuth authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-rar-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 12 08:23:30 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548423A0D7A for ; Sun, 12 Sep 2021 08:23: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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ILXu03Do3Vw for ; Sun, 12 Sep 2021 08:23:23 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CE43A0D77 for ; Sun, 12 Sep 2021 08:23:23 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id kt8so15201762ejb.13 for ; Sun, 12 Sep 2021 08:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Xu5Osm3SiuRy4yaf3Enn1XgfMpemKu0LtZmocCIfr08=; b=WcZtkmotGXUpSGfPqpU1RpoitAAFTTvuSPferDIVhwjJC65TFqLKOn2nMUrMoZwe78 d1CVdZpZagsrFtYI0cZNqMMr0hbahaZPu1HtA05IIIODEKCUszRRMtBcNEjHhAb4mB2Y 7+qs3W/5AL44Fkpp3GXOeA6IeCnIVOEunK96Lc8rlrDDp4fOb3I2cOV8Zipx5wxrOpw+ d0gseWZpGGuOVN8euC6xAQhzGBWSMPt0eliIhmm/brzZpeZYXvQPRMwbSVtpL9rXKzbg aB2Wmqqxc5kqA4LN43rNhvcB87iQXKTubbVoKaKO7q4ECo1Q7wj2UJU3nTAhAIUdqLMP tVAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Xu5Osm3SiuRy4yaf3Enn1XgfMpemKu0LtZmocCIfr08=; b=R4ZlRCVT7aVDEJKXgUFGBsixbmy8D3OWCnMya7Q3ZcO5kpmG2ALOUQEg9jkFOX38Rf J0BbmEWVj3pYgJuxjpc2WGHC5oUzB2XxUTJ/DD3jCvbzrlcHAqqChQ0mRa5Dk5zZ4P4U sCsBvjN3QFAtaBXuJnWOG1dXw+7/E7HX+Dh91uCa4yy6o98QAoFE7T2AWNrgnVJ0fAgU w7haxSizO7s+Zm4LxZ4jA/+YpJufB798ODHBYmBPWoZhQXKR952nXgddWKXPCStNJVp6 T8Nk13QAd2qqyLgaDrsUZK419S1PoIgCXk/tecOIx6eYGFCcQTFFQHUT2IanPyRYxKVk LYVA== X-Gm-Message-State: AOAM533wFbrzurb7xAOzDmykJqqFaHbaa1Ms8jI+2z8Hn3AxCqv0WhMI ZJ8CaY/X43Omg3ycPHPGuyjNoA== X-Google-Smtp-Source: ABdhPJz6yIUNrU5nvEEdZXchzEd3FsfdZdfBMBpe1OuGpMVx9SCkWe+BsU/LY9zfKeHoZx2IjPxX6A== X-Received: by 2002:a17:907:9602:: with SMTP id gb2mr7419150ejc.354.1631460200543; Sun, 12 Sep 2021 08:23:20 -0700 (PDT) Received: from smtpclient.apple ([46.183.103.8]) by smtp.gmail.com with ESMTPSA id l9sm2511953edt.55.2021.09.12.08.23.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Sep 2021 08:23:20 -0700 (PDT) From: Torsten Lodderstedt Message-Id: <9AF9025C-02A0-4454-9B35-BFC5943699A0@lodderstedt.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_296EE3A7-1CB2-4D12-86E9-425B03A3DA7C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sun, 12 Sep 2021 17:23:01 +0200 In-Reply-To: Cc: oauth , Justin Richer , Brian Campbell To: Rifaat Shekh-Yusef References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [OAUTH-WG] OAuth Interim Meetings X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 15:23:29 -0000 --Apple-Mail=_296EE3A7-1CB2-4D12-86E9-425B03A3DA7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, we would like to give an update on RAR. best regards, Torsten. > Am 05.09.2021 um 05:19 schrieb Aaron Parecki : >=20 > I would like to present on OAuth 2.1. >=20 > Separately, and preferably later in the series, I would like to = present on the Browser App BCP. >=20 > Thanks! >=20 > Aaron >=20 >=20 >=20 > On Sat, Sep 4, 2021 at 8:23 AM Rifaat Shekh-Yusef = > wrote: > All, >=20 > We would like to start a new series of interim meetings later in = September. > Please, let us know if you would like to present during one of these = meetings. >=20 > Regards, > Rifaat & Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > --=20 > --- > Aaron Parecki > https://aaronparecki.com = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1631416799000000&usg=3DAOvVaw0Tjp5Vv2d_eaYA42SV= FIeu --Apple-Mail=_296EE3A7-1CB2-4D12-86E9-425B03A3DA7C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

we = would like to give an update on RAR.

best regards,
Torsten.

Am = 05.09.2021 um 05:19 schrieb Aaron Parecki <aaron@parecki.com>:

I would like to present on OAuth 2.1.

Separately, and preferably later in the series, I would like = to present on the Browser App BCP.

Thanks!

Aaron



On Sat, Sep = 4, 2021 at 8:23 AM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
All,

We would like to start a = new series of interim meetings later in September.
Please, let us know if you would like to present during one = of these meetings.

Regards,
 Rifaat & = Hannes

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

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/lis= tinfo/oauth&source=3Dgmail-imap&ust=3D1631416799000000&usg=3DA= OvVaw0Tjp5Vv2d_eaYA42SVFIeu

= --Apple-Mail=_296EE3A7-1CB2-4D12-86E9-425B03A3DA7C-- From nobody Sun Sep 12 08:32:03 2021 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 8E7FF3A0E30; Sun, 12 Sep 2021 08:31: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: 7.37.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: oauth@ietf.org Message-ID: <163146070145.15835.6588780476124688306@ietfa.amsl.com> Date: Sun, 12 Sep 2021 08:31:41 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 15:31:42 -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 Rich Authorization Requests Authors : Torsten Lodderstedt Justin Richer Brian Campbell Filename : draft-ietf-oauth-rar-07.txt Pages : 41 Date : 2021-09-12 Abstract: This document specifies a new parameter "authorization_details" that is used to carry fine-grained authorization data in the OAuth authorization request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-rar-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-rar-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Sep 12 08:37:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D693A0EEA for ; Sun, 12 Sep 2021 08:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5IXdiCZ8POE for ; Sun, 12 Sep 2021 08:37:28 -0700 (PDT) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450: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 EAADD3A0EE8 for ; Sun, 12 Sep 2021 08:37:27 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id o20so4662518ejd.7 for ; Sun, 12 Sep 2021 08:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=aw0mMTUKBXAWmPFFIPFEq3oZNmISB5eiFudMGQIl5F8=; b=UjqNQfQdvlzaCKMzDuj5IdOoZ9E2DDiX87grmCV8qAnou+A674wJgRdxQYUpcnJWXk gXVQha7DKDLhhyL7dEQqcn0Q0A6nOMPgpavQMwSusis6dwljBYbx+c2OCF3r7HJmGfl9 rxai+MdpN6/HqzvLxg/zYwcvvu+uNf7DLo4zF8WZHkq+oz95P+1BpAnI0WWL0PLnGQ5D fg+DHeY1X7F7TD2vvp+ViajIqMxyyurLtGqirNTvzMBJ/YL3XHmESQLzvcWKFBufoIqv lyqsvz8L8Oi1DNxf2fPDLEox6YZNaybI6esxPJi8pl/rLwTt4Z2XfkHMyJc3Wo4Ca/WE Ncfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=aw0mMTUKBXAWmPFFIPFEq3oZNmISB5eiFudMGQIl5F8=; b=K9tbcy9oHCM3sc4NvAoIdRsjokVsTRn/ZIHI2IY4fXW4j+ME7nO4llDzC++x+Y+jMY Y/J7DK1kiTjXMJyjjA+9K6pzDUcM2QVDABTlpseObAHsfTIJ/YHFpCqrpdZfJ5slf+WH cyUQk668eSh4PvnsX5Fpth0vzPo2aA8mKgBLyIngz+VCBeGW3FgGfRq7oFGQ7zTHphLJ 0n4aymxcc9q3q35Qp1ItHtgzyubWEmzbzd5ZDedg3FFm2KPOXAhrtVr9ZsZIoOhUl0yT zIqCAeywKJ4d0TDinybpttTT/O0TgvyyAJzPgQwF5we+c3GnKt4ypGLsIThRmURWedGS 9NOA== X-Gm-Message-State: AOAM533/Jmz6rLk966zK/fFcQwIy1RTlfwE2d6dgEby0wj8Gbye6V7Ww bcjHibfz1vz1smc9AqFiYRa2u403yb1OU3tD X-Google-Smtp-Source: ABdhPJzgmKihSZZ7Q+dc14VSZqz4uOTKXzyFZvmKRlpW9FT4EosXWW2sR/kwsgiGCkq95LDJ00LQGw== X-Received: by 2002:a17:907:1de0:: with SMTP id og32mr8015024ejc.348.1631461045409; Sun, 12 Sep 2021 08:37:25 -0700 (PDT) Received: from smtpclient.apple ([46.183.103.8]) by smtp.gmail.com with ESMTPSA id j5sm2169973ejb.96.2021.09.12.08.37.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Sep 2021 08:37:25 -0700 (PDT) From: Torsten Lodderstedt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sun, 12 Sep 2021 17:37:15 +0200 References: <163146070145.15835.6588780476124688306@ietfa.amsl.com> To: oauth In-Reply-To: <163146070145.15835.6588780476124688306@ietfa.amsl.com> Message-Id: <82D850BB-1BBE-426D-B4BD-862575F6C22E@lodderstedt.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-07.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: Sun, 12 Sep 2021 15:37:33 -0000 Hi all, we published a new revision -07 containing the following changes: =E2=80=A2 removed use of resource indicators to filter = authorization details in token response (to simplify spec) =E2=80=A2 incorporated review feedback from WGLC =E2=80=A2 fixed wording in token introspection section =E2=80=A2 added privacy considerations re authorization details = in token response Thanks to all the reviewers! best regards, Torsten.=20 > Am 12.09.2021 um 17:31 schrieb internet-drafts@ietf.org: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Web Authorization Protocol WG of the = IETF. >=20 > Title : OAuth 2.0 Rich Authorization Requests > Authors : Torsten Lodderstedt > Justin Richer > Brian Campbell > Filename : draft-ietf-oauth-rar-07.txt > Pages : 41 > Date : 2021-09-12 >=20 > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine-grained authorization data in the OAuth > authorization request. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://www.google.com/url?q=3Dhttps://datatracker.ietf.org/doc/draft-ietf= -oauth-rar/&source=3Dgmail-imap&ust=3D1632065562000000&usg=3DAOvVaw2mNxPXx= bjUclgOYKnqcoWm >=20 > There is also an HTML version available at: > = https://www.google.com/url?q=3Dhttps://www.ietf.org/archive/id/draft-ietf-= oauth-rar-07.html&source=3Dgmail-imap&ust=3D1632065562000000&usg=3DAOvVaw3= H8e6Las-aD9X70yWaIawL >=20 > A diff from the previous version is available at: > = https://www.google.com/url?q=3Dhttps://www.ietf.org/rfcdiff?url2%3Ddraft-i= etf-oauth-rar-07&source=3Dgmail-imap&ust=3D1632065562000000&usg=3DAOvVaw1K= Ag4Yy6K3TChmooA2YVmP >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > = https://www.google.com/url?q=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1632065562000000&usg=3DAOvVaw1w7aPQ263YvHjFUJZZ= Qq8r From nobody Wed Sep 15 12:24:18 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A843A08D8; Wed, 15 Sep 2021 12:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kxWc6MxfKvfA; Wed, 15 Sep 2021 12:24:03 -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 874D23A08A9; Wed, 15 Sep 2021 12:24:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A0937F40719; Wed, 15 Sep 2021 12:23:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210915192324.A0937F40719@rfc-editor.org> Date: Wed, 15 Sep 2021 12:23:24 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] =?utf-8?q?RFC_9126_on_OAuth_2=2E0_Pushed_Authorizatio?= =?utf-8?q?n_Requests?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 19:24:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9126 Title: OAuth 2.0 Pushed Authorization Requests Author: T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. Skokan Status: Standards Track Stream: IETF Date: September 2021 Mailbox: torsten@lodderstedt.net, bcampbell@pingidentity.com, nat@sakimura.org, dave@tonge.org, panva.ip@gmail.com Pages: 18 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-par-10.txt URL: https://www.rfc-editor.org/info/rfc9126 DOI: 10.17487/RFC9126 This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Sep 17 10:04:09 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABD53A0857 for ; Fri, 17 Sep 2021 10:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 UuNBzN4lYn6f for ; Fri, 17 Sep 2021 10:04:01 -0700 (PDT) Received: from na01-obe.outbound.protection.outlook.com (mail-oln040093003001.outbound.protection.outlook.com [40.93.3.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D692C3A0856 for ; Fri, 17 Sep 2021 10:04:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dsEnXY285rCOURSkV9LPuI8lZTk4R0kjdGZGMIzvaNFnsVEKKUsaDLGLbi2abvJiNJ2G39oJR7JvST6qX3r2BUKifLa3BVbAKlRAqKH2zM8zcw9SPjcT6LWjGbNB31KFNuSgGQEBraf6Gy8J9G6Z6IBni63u5E6V+Ynw9AGbRtCTF5UJwYHuEHcNSJ/45PbNFtR+9wltmkMX9YUYZ2p3B8NlBoRcMyX4X0vh/jIbIWyqDDL0kkWA9fq+DjLwk/mEe6A/W6gzA50yX40CmJ8D9PY1OE3GhN57fjaMI4oBZqmleteqQZhmtLjdZSXh0TopiH/XEZQkfNApcJnxbUT+6w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sM9sEizcJbqO9dGNBp9qg3HPFTtrTwevO3aezvDd83s=; b=dzEqk391AtXTv5jKLQjlli5qF3rAINEG0Wx0GHO+zOcZHtB4mfek/ReqKlnDU/kv3HreYArY48Mfy9Ug2a9IYjmArpzyJSOYb/xhqq8bXySnFyOBldEcdVsTm28r6WXraS4w9TR1bumJFkQNoB2DjAUzyv7WIyXG+AGgEYnVxwCn2+FZNNiCHlzb9s3ZZyZ0PX1Wzz0aJ3iVDX4MJjqbbfYDmDlZsmdQbKj2EFXOVmkdzWyM80F1AvSpsGavx6/thEVpbRJrtGyNVxnyLAmMzFPTrAz3732Zq3UdLczF5dZEdzenOMoWyb4kw8Y4TvVNAm7OZMrIh4oNtspW2QVPYw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sM9sEizcJbqO9dGNBp9qg3HPFTtrTwevO3aezvDd83s=; b=baMDpeJa5jzuRrVHbzWku4dqfrdQNADcb5yAE1sgL3eBuJa/vgVYjZsNXDsA6e1NOx49ovCXmW/mGQGI+pUdS7frqCOsi/3JH6OICkpmg1y1WfJp4JpTzG1pv4RRqX7whODbqafF1iYZndHHb1QULFKaqjEuB58S373YXjJY8Zc= Received: from PH0PR00MB0997.namprd00.prod.outlook.com (2603:10b6:510:33::14) by PH0PR00MB1229.namprd00.prod.outlook.com (2603:10b6:510:9d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4564.0; Fri, 17 Sep 2021 17:03:58 +0000 Received: from PH0PR00MB0997.namprd00.prod.outlook.com ([fe80::e87e:40eb:e11c:73aa]) by PH0PR00MB0997.namprd00.prod.outlook.com ([fe80::e87e:40eb:e11c:73aa%3]) with mapi id 15.20.4568.000; Fri, 17 Sep 2021 17:03:58 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Adding the option to use server-supplied nonces to DPoP Thread-Index: Adeq9U243kUYMdc0TkujRKK/z5P5mQ== Date: Fri, 17 Sep 2021 17:03:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-09-16T12:18:42Z; 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_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=834c9701-4771-442b-b693-468383c13578; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdfe3884-0803-411f-778d-08d979fd23ae x-ms-traffictypediagnostic: PH0PR00MB1229: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: a7V25k/UjkfD/WBG73Q+bPfl+km8VzCVVyGfuW2vNAiUh976u6G1/ikDxgLaJ3Ve6G8SPaSif0TVX0yiqdy3gLhVCl878AdhZXcLVNJVdqHW1OdksZ310P2QzwI8JiXZYlxXcSn5HpVE7/BQDKnD/8G7LL7ikJnfcmA1U9JuqMt5wZ9w3rRjKxT2DAB1K148V0PZAyD5Q3XBx8/RbbaJkW9eNN1uTFCzdivesCeH/hF4ZAik5LgPFAn5yJX4R8hxk+Y5jii3dYytYmQS+l3rnc849ev/hA2ZoD79xWAmABh8SxFE09USfcg0b1FW8w9PyomW8MOAXb2yWHKf0XTAU4ro4UZ0H8gEfqTT2Q+pqjhv+d11TkxlmOjGgBEju76RA6h0FCs8MInB20T63n9ClxvdPYBMz8xpbLbBz6yuTpJ6IGwG8V3EWDxvzQkIuqllLvcgGADftgVqWPC3n7oofUd8ULsu+8LFZ53tK+5J93Jm9xr5dKGKAmqhzuNH/esFxtRZfhYmy9nU8VZd5/z4zlXyDsbRBpLLNlmILJillVT3n4Q0IahnwPIpn+qIPLyFHZgiN1tZxPKvQdhkRtfM8Aui4OE1fHgSbhcMD2o/5Psb8Z9eiCQJBTpaDlElaSz7l9RnedRtfYevY1E+vLsy5u3v44l8qZQWVn8BCtgKRSi+AJ9nioZn5zinfakBsmDK8VfCEz7ldei2uLAy0lXlFBPw3q4AadxZA/atewkDGLGdEMDf2cYQETt8g7aiaDgVEE5R/03VmFhV4UqLQnl/nGewnUOseV1UDpag9LB9iQLaHgY8t2M7ldf80fUrnvslc+LI7XgL7WWmwAP/v5lrnQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR00MB0997.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(76116006)(186003)(7696005)(508600001)(82950400001)(10290500003)(71200400001)(166002)(6506007)(66556008)(66574015)(107886003)(9686003)(52536014)(66476007)(122000001)(8936002)(8676002)(66446008)(64756008)(38070700005)(2906002)(83380400001)(6916009)(38100700002)(33656002)(5660300002)(8990500004)(316002)(26005)(966005)(86362001)(82960400001)(4326008)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?okFOLYJJbRsb5j3r3jEqSySL/Jb60GN8yZtRsZVyojNWXHe4kjlmmaBNyeti?= =?us-ascii?Q?K7hyoUgZYt9i1WnRLPFPGCiJbyYT6bHPW/6LI9tvppGLKXVaKh9bUrMjP4FA?= =?us-ascii?Q?bM0OKwn3pMmR1rE3l7HJUO21uRxric589+FwV9ZvQi4Ik8rLCW8TdqZpBOTG?= =?us-ascii?Q?zEfVy1YSTS64XOFquEay0BWctBCOzlpE2WmitNhJZhjNqwCDtmbZglAK4KPt?= =?us-ascii?Q?ljnii9zNAiHwa7bSqu7a+A6Nkiiis5kG/h0gcUJ96v+7C+m14P8/epppvHf0?= =?us-ascii?Q?2d/9PSHyULxgut+7uw1fKCGnP9qz5dYHshUeLVN+vfYiA/n8DIkkBeZT8UOD?= =?us-ascii?Q?gyCf7GshVmPuAvOMOdr1tWKhgk0XYanI/taA48jQJ7AtP5XLl8K4+4JzMvAI?= =?us-ascii?Q?q2RmnaQTj8d5vKE168Zo1DZs41TFrLK4eAGDVHGnSfdGC6xMohLRlCG9VSe1?= =?us-ascii?Q?EEVKkWWyw4JsqpUqQrK+7wBQitd7Bgc2scq4JWknpHXm69GLG37HeeMYAf6H?= =?us-ascii?Q?qXFFBEnKl64lpWv7m40qSnwFhiWvB3q+V0hKDOfOhVWXZUucrZj2HwAMV+NJ?= =?us-ascii?Q?S1PrY2DsEEL8Yjx0wQL269U7VZC19fPhhp2uQp0WR1aIOX6SD13AHWcn3iR4?= =?us-ascii?Q?8Jq/XN+6938sy+pgR4ffSIljWVG8x+9As0tWzPCmz0lqjW1L+u/Mu3AEHvWG?= =?us-ascii?Q?cOc7V5Oh2lYNEuhLcxKvmIjWymWexvRsNTLpxmtRrgmWdSLaz2RiWBbYfJGw?= =?us-ascii?Q?5i0ufzJxoa0zk/W8vj5tnByHVvVZp2D88B8BhmQfjoue/zxmgkIzwHK1VO1H?= =?us-ascii?Q?LUuT3KSXqeD9CbwjP1xX63o6xtDZiPk+A2oMWH9Bv9QIW1j49ytMB/+N+8BX?= =?us-ascii?Q?Lo4k4LFxlj9RCaMlqnQID6freTluvJ5V5JhzKaJnUY/bcz8KRid1EBBs3DVf?= =?us-ascii?Q?HgRNJyVvmUI2fEeQhufNh81CDI8lNnWR7tN6BlOG07nKJFhpBo0xV8W1K06N?= =?us-ascii?Q?WF+Pk4qrEPmG4R6CDad3V/VGhJEt1L8xnQbqAbFdUza+bQXnR4lTFY5omz7B?= =?us-ascii?Q?GgCVgo5pumJQK/ua4vy6T1hAX/e7G1Fi70beI0DS5zNP3PKXii2gtNGetA6r?= =?us-ascii?Q?xaj6JHGSHgugHuofRx8htbBjOcKyvubH9adeuNLxIQ/3DNAEebg1jkYuRSXX?= =?us-ascii?Q?OcHskdP2WaaWEuu8od5HY2sve/JFxCp1/LaVCnJ0tkKZwXdGzrN+H24a7Z0y?= =?us-ascii?Q?1yHzHgskK3MWfDTwGaiIF3gCDz1j10Un6l9cPgA7Fmt6Vq2fFAvL0gQYh2/5?= =?us-ascii?Q?aAY=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR00MB099738694FBE4FAFCA0E5C2DF5DD9PH0PR00MB0997namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR00MB0997.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdfe3884-0803-411f-778d-08d979fd23ae X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2021 17:03:58.1272 (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: bTzVe6bDyFpB6s++gxG8lea1r+sKS/CLy7FfjaCq7Gr+KivHb+6U71g5IEwFO54cVxq2ScRx69+Jlv4l2zRs/A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR00MB1229 Archived-At: Subject: [OAUTH-WG] Adding the option to use server-supplied nonces to 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: Fri, 17 Sep 2021 17:04:07 -0000 --_000_PH0PR00MB099738694FBE4FAFCA0E5C2DF5DD9PH0PR00MB0997namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We all know that using proof-of-possession with issued tokens is a means of= rendering exfiltrated tokens useless to attackers. The DPoP was created a= s one of the tools to prevent this. There's a huge amount of evidence of s= uccessful token exfiltration attacks in the wild, some of which is referenc= ed at the end of this message. For instance, sometimes the legitimate user= of a client is the attacker. Once instance of this is that some banks hav= e cited employees stealing legitimate tokens issued on bank computers and t= aking them to non-bank computers, thereby bypassing audit controls. When reviewing DPoP with Microsoft's identity architects, they pointed out = that DPoP as written today can still enable exfiltrated DPoP tokens to be u= sed by some kinds of attackers; doing so also requires that the attackers e= xfiltrate DPoP proofs. This is possible when the legitimate user of a clie= nt is the attacker. Preventing exfiltrated pre-generated DPoP proofs from being used in the fut= ure requires the server being able to limit their lifetime. An effective m= eans of doing this is to include a server-provided nonce in the DPoP proof.= That puts the lifetime of DPoP proofs in control of the server, because w= hen a new nonce value is provided, older, possibly pre-generated DPoP proof= s become invalid at the server. The Microsoft identity server team is already internally using this techniq= ue with the stale OAuth HTTP Signing draft. They want to be able to use it= with DPoP for the same reasons. DPoP without this won't mitigate the real= security attacks that our systems are encountering. Note that unless a se= rver-provided nonce is used, what is actually being proved is possession of= a DPoP proof - not possession of the proof-of-possession key. Having discussed this with some of the editors, I have created a pull reque= st adding the optional use of server-provided nonces to DPoP. This will br= eak no existing deployments. But it will enable new deployments to choose = to use server-contributed nonces to limit DPoP proof lifetimes, both for au= thorization servers and resource servers. The pull request is at https://g= ithub.com/danielfett/draft-dpop/pull/81/. Reviews of the PR are welcomed. = I propose that we merge it and publish draft -04 sometime next week, pendi= ng review feedback. =3D=3D=3D=3D My colleague Pieter Kasselman assembled some examples of successful token e= xfiltration attacks in the public domain (and helped review the PR). Those= follow, for your reading pleasure. 1. Introducing a new phishing technique for compromising Office 365 acco= unts (o365blog.com) * It describes a phishing attack that allows the attacker to obtain = an Access Token and a Refresh Token (which is then used to obtain additiona= l Access Tokens). * Operationalised with the AADInternals Tool 2. The Art of the Device Code Phish - Boku (0xboku.com) * It extends the above attack and shows step-by-step how to exfiltra= te a Access Token and a Refresh Token with a similar phishing attack and th= en obtain additional tokens. * Operationalised with AADInternals and TokenTactics 1. DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Auth= entication Flows - YouTube * It shows another attack to exfiltrate tokens using phishing techni= ques that exploit Device Code Flow. * It includes a demo of the attack that shows how it bypasses MFA an= d anti-Phishing controls and then uses the PRT to get tokens and pivot to o= ther services. * Tools available as open source. 1. Requesting Azure AD Request Tokens on Azure-AD-joined Machines for Br= owser SSO | by Lee Christensen | Posts By SpecterOps Team Members * Outlines how a Refresh Token can be exfiltrated from a Chrome brow= ser * Operationalised with a tool called RequestAADRefreshToken 1. Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io * Extracts the Primary Refresh Token through Chrome * Requires executing code on the users device to interact with the C= hrome browser, executed in the user context, no elevated privileges needed * Operationalised through ROADtoken and ROADtools. 1. Digging further into the Primary Refresh Token - dirkjanm.io * Describes how the PRT and session keys can be extracted from a dev= ice (requires local admin) * Operationalised through ROADtools -- Mike --_000_PH0PR00MB099738694FBE4FAFCA0E5C2DF5DD9PH0PR00MB0997namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We all know that using proof-of-possession with issu= ed tokens is a means of rendering exfiltrated tokens useless to attackers.&= nbsp; The DPoP was created as one of the tools to prevent this.  There= ’s a huge amount of evidence of successful token exfiltration attacks in the wild, some of which is referenced at the end o= f this message.  For instance, sometimes the legitimate user of a clie= nt is the attacker.  Once instance of this is that some banks have cit= ed employees stealing legitimate tokens issued on bank computers and taking them to non-bank computers, thereby bypassing= audit controls.

 

When reviewing DPoP with Microsoft’s identity = architects, they pointed out that DPoP as written today can still enable ex= filtrated DPoP tokens to be used by some kinds of attackers; doing so also = requires that the attackers exfiltrate DPoP proofs.  This is possible when the legitimate user of a client is the= attacker.

 

Preventing exfiltrated pre-generated DPoP proofs fro= m being used in the future requires the server being able to limit their li= fetime.  An effective means of doing this is to include a server-provi= ded nonce in the DPoP proof.  That puts the lifetime of DPoP proofs in control of the server, because when a new n= once value is provided, older, possibly pre-generated DPoP proofs become in= valid at the server.

 

The Microsoft identity server team is already intern= ally using this technique with the stale OAuth HTTP Signing draft.  Th= ey want to be able to use it with DPoP for the same reasons.  DPoP wit= hout this won’t mitigate the real security attacks that our systems are encountering.  Note that unless a server-provide= d nonce is used, what is actually being proved is possession of a DPoP proo= f – not possession of the proof-of-possession key.

 

Having discussed this with some of the editors, I ha= ve created a pull request adding the optional use of server-provided nonces= to DPoP.  This will break no existing deployments.  But it will = enable new deployments to choose to use server-contributed nonces to limit DPoP proof lifetimes, both for authorization servers and r= esource servers.  The pull request is at https://githu= b.com/danielfett/draft-dpop/pull/81/.  Reviews of the PR are welco= med.  I propose that we merge it and publish draft -04 sometime next w= eek, pending review feedback.

 

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

 

My colleague Pieter Kasselman assembled some example= s of successful token exfiltration attacks in the public domain (and helped= review the PR).  Those follow, for your reading pleasure.

  1. Introducing a new phishing technique for compromising Office 365 accounts (o365blog.co= m)
    1. It describes a phishing attack that allows the attacke= r to obtain an Access Token and a Refresh Token (which is then used to obta= in additional Access Tokens).
    2. Operationalised with the AADInternals Tool<= /span>
  2. The Art of the Device Code Phish - Boku (0xboku.com)
    1. It extends the above attack and shows step-by-step how= to exfiltrate a Access Token and a Refresh Token with a similar phishing a= ttack and then obtain additional tokens.
    2. Operationalised with AADInternals and TokenTactics
  1. DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authenticatio= n Flows - YouTube
    1. It shows another attack to exfiltrate tokens using phi= shing techniques that exploit Device Code Flow.
    2. It includes a demo of the attack that shows how it byp= asses MFA and anti-Phishing controls and then uses the PRT to get tokens an= d pivot to other services.
    3. Tools available as open source.
      4. =
  1. Requesting Azure AD Request Tokens on Azure-AD-joined Machines for Browser SSO | by L= ee Christensen | Posts By SpecterOps Team Members
    1. Outlines how a Refresh Token can be exfiltrated from a= Chrome browser
    2. Operationalised with a tool called RequestAADRefreshTo= ken
  1. Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io
    1. Extracts the Primary Refresh Token through Chrome=
    2. Requires executing code on the users device to interac= t with the Chrome browser, executed in the user context, no elevated privil= eges needed
    3. Operationalised through ROADtoken and ROADtools.<= /o:p>
  1. Digging further into the Primary Refresh Token - dirkjanm.io=
    1. Describes how the PRT and session keys can be extracte= d from a device (requires local admin)
    2. Operationalised through ROADtools

     =             &nb= sp;            =             &nb= sp;            -- Mi= ke

 

--_000_PH0PR00MB099738694FBE4FAFCA0E5C2DF5DD9PH0PR00MB0997namp_-- From nobody Fri Sep 17 13:12:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4FB3A1267; Fri, 17 Sep 2021 13:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_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 ERdc1Gc6fN22; Fri, 17 Sep 2021 13:12:26 -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 87BD83A1268; Fri, 17 Sep 2021 13:12:25 -0700 (PDT) Received: from [192.168.1.28] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 18HKCNwV026757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Sep 2021 16:12:23 -0400 From: Justin Richer Message-Id: <033CE24C-C143-4067-AA67-012A41EBB9DD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Fri, 17 Sep 2021 16:12:23 -0400 In-Reply-To: Cc: "oauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [OAUTH-WG] Adding the option to use server-supplied nonces to 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: Fri, 17 Sep 2021 20:12:31 -0000 --Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, thanks for this writeup and bringing this attack surface to the = attention of the group! I would like to also discuss how this attack and = solution could be applied to the proposed HTTP Message Signatures based = draft for OAuth 2: https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.html = The generic HTTP Message Signatures draft already includes a =E2=80=9Cnonc= e=E2=80=9D parameter that can be used with the signature, so no new = fields need to be defined: = https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-06.h= tml#section-2.3.1-4.3 = However, the OAuth2 application draft doesn=E2=80=99t currently do = anything special with this parameter. If I=E2=80=99m reading this PR for = DPoP and the surrounding issues correctly, then I believe the one = missing piece is adding the `nonce=3D=E2=80=A6` portion to the = `WWW-Authenticate` response header, and requiring the client to use that = on the next request. The OAuth2-httpsig draft doesn=E2=80=99t define a = use of this header, yet, but I could see something similar happening = there. However, I=E2=80=99m also wondering if this is something we should bring = to the HTTP working group and have something in the full HTTP Message = Signatures draft. This draft doesn=E2=80=99t deal with the = `Authorization` or `WWW-Authenticate` headers, but it does define an = `Accept-Signature` header to signal required parameters and signed = components, for exactly this kind of negotiation. The OAuth2-httpsig = draft could simply direct the AS/RS to return this `Accept-Signature` = header with a nonce field in order to cause the client to sign = subsequent requests using the server-provided nonce. What are your thoughts on these proposals? =E2=80=94 Justin > On Sep 17, 2021, at 1:03 PM, Mike Jones = wrote: >=20 > We all know that using proof-of-possession with issued tokens is a = means of rendering exfiltrated tokens useless to attackers. The DPoP = was created as one of the tools to prevent this. There=E2=80=99s a huge = amount of evidence of successful token exfiltration attacks in the wild, = some of which is referenced at the end of this message. For instance, = sometimes the legitimate user of a client is the attacker. Once = instance of this is that some banks have cited employees stealing = legitimate tokens issued on bank computers and taking them to non-bank = computers, thereby bypassing audit controls. > =20 > When reviewing DPoP with Microsoft=E2=80=99s identity architects, they = pointed out that DPoP as written today can still enable exfiltrated DPoP = tokens to be used by some kinds of attackers; doing so also requires = that the attackers exfiltrate DPoP proofs. This is possible when the = legitimate user of a client is the attacker. > =20 > Preventing exfiltrated pre-generated DPoP proofs from being used in = the future requires the server being able to limit their lifetime. An = effective means of doing this is to include a server-provided nonce in = the DPoP proof. That puts the lifetime of DPoP proofs in control of the = server, because when a new nonce value is provided, older, possibly = pre-generated DPoP proofs become invalid at the server. > =20 > The Microsoft identity server team is already internally using this = technique with the stale OAuth HTTP Signing draft. They want to be able = to use it with DPoP for the same reasons. DPoP without this won=E2=80=99t= mitigate the real security attacks that our systems are encountering. = Note that unless a server-provided nonce is used, what is actually being = proved is possession of a DPoP proof =E2=80=93 not possession of the = proof-of-possession key. > =20 > Having discussed this with some of the editors, I have created a pull = request adding the optional use of server-provided nonces to DPoP. This = will break no existing deployments. But it will enable new deployments = to choose to use server-contributed nonces to limit DPoP proof = lifetimes, both for authorization servers and resource servers. The = pull request is at https://github.com/danielfett/draft-dpop/pull/81/ = . Reviews of the PR = are welcomed. I propose that we merge it and publish draft -04 sometime = next week, pending review feedback. > =20 > =3D=3D=3D=3D > =20 > My colleague Pieter Kasselman assembled some examples of successful = token exfiltration attacks in the public domain (and helped review the = PR). Those follow, for your reading pleasure. > Introducing a new phishing technique for compromising Office 365 = accounts (o365blog.com) = > It describes a phishing attack that allows the attacker to obtain an = Access Token and a Refresh Token (which is then used to obtain = additional Access Tokens). > Operationalised with the AADInternals Tool > The Art of the Device Code Phish - Boku (0xboku.com) = = > It extends the above attack and shows step-by-step how to exfiltrate a = Access Token and a Refresh Token with a similar phishing attack and then = obtain additional tokens. > Operationalised with AADInternals and TokenTactics > DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth = Authentication Flows - YouTube = > It shows another attack to exfiltrate tokens using phishing techniques = that exploit Device Code Flow. > It includes a demo of the attack that shows how it bypasses MFA and = anti-Phishing controls and then uses the PRT to get tokens and pivot to = other services. > Tools available as open source. > Requesting Azure AD Request Tokens on Azure-AD-joined Machines for = Browser SSO | by Lee Christensen | Posts By SpecterOps Team Members = > Outlines how a Refresh Token can be exfiltrated from a Chrome browser > Operationalised with a tool called RequestAADRefreshToken > Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io = > Extracts the Primary Refresh Token through Chrome > Requires executing code on the users device to interact with the = Chrome browser, executed in the user context, no elevated privileges = needed > Operationalised through ROADtoken and ROADtools. > Digging further into the Primary Refresh Token - dirkjanm.io = > Describes how the PRT and session keys can be extracted from a device = (requires local admin) > Operationalised through ROADtools=20 > -- Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mike, thanks for this writeup and bringing this attack surface to the = attention of the group! I would like to also discuss how this attack and = solution could be applied to the proposed HTTP Message Signatures based = draft for OAuth 2:

https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-00.h= tml

The = generic HTTP Message Signatures draft already includes a =E2=80=9Cnonce=E2= =80=9D parameter that can be used with the signature, so no new fields = need to be defined:

https://www.ietf.org/archive/id/draft-ietf-httpbis-message-sign= atures-06.html#section-2.3.1-4.3

However, the OAuth2 application draft = doesn=E2=80=99t currently do anything special with this parameter. If = I=E2=80=99m reading this PR for DPoP and the surrounding issues = correctly, then I believe the one missing piece is adding the = `nonce=3D=E2=80=A6` portion to the `WWW-Authenticate` response header, = and requiring the client to use that on the next request. The = OAuth2-httpsig draft doesn=E2=80=99t define a use of this header, yet, = but I could see something similar happening there.

However, I=E2=80=99m = also wondering if this is something we should bring to the HTTP working = group and have something in the full HTTP Message Signatures draft. This = draft doesn=E2=80=99t deal with the `Authorization` or = `WWW-Authenticate` headers, but it does define an `Accept-Signature` = header to signal required parameters and signed components, for exactly = this kind of negotiation. The OAuth2-httpsig draft could simply direct = the AS/RS to return this `Accept-Signature` header with a nonce field in = order to cause the client to sign subsequent requests using the = server-provided nonce.

What are your thoughts on these proposals?

 =E2=80=94 = Justin

On Sep 17, 2021, at 1:03 PM, Mike Jones = <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

We all know that using = proof-of-possession with issued tokens is a means of rendering = exfiltrated tokens useless to attackers.  The DPoP was created as = one of the tools to prevent this.  There=E2=80=99s a huge amount of = evidence of successful token exfiltration attacks in the wild, some of = which is referenced at the end of this message.  For instance, = sometimes the legitimate user of a client is the attacker.  Once = instance of this is that some banks have cited employees stealing = legitimate tokens issued on bank computers and taking them to non-bank = computers, thereby bypassing audit controls.
 
When reviewing DPoP with = Microsoft=E2=80=99s identity architects, they pointed out that DPoP as = written today can still enable exfiltrated DPoP tokens to be used by = some kinds of attackers; doing so also requires that the attackers = exfiltrate DPoP proofs.  This is possible when the legitimate user = of a client is the attacker.
 
Preventing exfiltrated pre-generated DPoP proofs = from being used in the future requires the server being able to limit = their lifetime.  An effective means of doing this is to include a = server-provided nonce in the DPoP proof.  That puts the lifetime of = DPoP proofs in control of the server, because when a new nonce value is = provided, older, possibly pre-generated DPoP proofs become invalid at = the server.
 
The Microsoft identity = server team is already internally using this technique with the stale = OAuth HTTP Signing draft.  They want to be able to use it with DPoP = for the same reasons.  DPoP without this won=E2=80=99t mitigate the = real security attacks that our systems are encountering.  Note that = unless a server-provided nonce is used, what is actually being proved is = possession of a DPoP proof =E2=80=93 not possession of the = proof-of-possession key.
 
Having discussed this with = some of the editors, I have created a pull request adding the optional = use of server-provided nonces to DPoP.  This will break no existing = deployments.  But it will enable new deployments to choose to use = server-contributed nonces to limit DPoP proof lifetimes, both for = authorization servers and resource servers.  The pull request is = at https://github.com/danielfett/draft-dpop/pull/81/.  = Reviews of the PR are welcomed.  I propose that we merge it and = publish draft -04 sometime next week, pending review feedback.
 
=3D=3D=3D=3D
 
My colleague Pieter = Kasselman assembled some examples of successful token exfiltration = attacks in the public domain (and helped review the PR).  Those = follow, for your reading pleasure.
  1. Introducing a new phishing technique for = compromising Office 365 accounts (o365blog.com)
    1. It describes a = phishing attack that allows the attacker to obtain an Access Token and a = Refresh Token (which is then used to obtain additional Access = Tokens).
    2. Operationalised = with the AADInternals Tool
  2. The Art of the Device Code Phish = - Boku (0xboku.com)
    1. It extends the above attack and shows step-by-step how to = exfiltrate a Access Token and a Refresh Token with a similar phishing = attack and then obtain additional tokens.
    2. Operationalised with = AADInternals and TokenTactics
  1. DEF CON 29 - Jenko Hwong - New Phishing Attacks = Exploiting OAuth Authentication Flows - YouTube
    1. It shows = another attack to exfiltrate tokens using phishing techniques that = exploit Device Code Flow.
    2. It includes a demo of the attack that shows how it bypasses = MFA and anti-Phishing controls and then uses the PRT to get tokens and = pivot to other services.
    3. Tools available as open source.
  1. Requesting Azure AD Request Tokens on = Azure-AD-joined Machines for Browser SSO | by Lee Christensen | Posts By = SpecterOps Team Members
    1. Outlines how a Refresh Token can be exfiltrated from a Chrome = browser
    2. Operationalised = with a tool called RequestAADRefreshToken
  1. Abusing Azure AD SSO = with the Primary Refresh Token - dirkjanm.io
    1. Extracts the = Primary Refresh Token through Chrome
    2. Requires executing code on the users device to interact with = the Chrome browser, executed in the user context, no elevated privileges = needed
    3. Operationalised = through ROADtoken and ROADtools.
    Digging further into the = Primary Refresh Token - dirkjanm.io
    1. Describes how = the PRT and session keys can be extracted from a device (requires local = admin)
    2. Operationalised = through ROADtools 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_910FFD50-5212-4275-88D6-F3ABDE6A5216-- From nobody Fri Sep 17 15:39:59 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EDC3A1981 for ; Fri, 17 Sep 2021 15:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=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 3dkOVg_-PlCo for ; Fri, 17 Sep 2021 15:39:52 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B366D3A197D for ; Fri, 17 Sep 2021 15:39:51 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id y28so37985346lfb.0 for ; Fri, 17 Sep 2021 15:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GXGxQxgfe8PHQvcuCd5BuJZbNb5Qaszh2FSV9QhQLvw=; b=T9V6F5oAQMaX+UtUpJqFx/1Nt68123lzXYgkj+bR5K78JtUjVrbd7iisvtAwSTCgGs 5Ce3XdgbwbolMawgfv6n6B78aYu91hpndn2KE2jPhya/OIt/Nm46GqYAvyHEINOR3jFs c2sD5FI1vwUR0LZQVS7vjmvisIyLmkIxmDYdl+R96iTA83G44DRg17K5pHfpfD9iP0sf 6xonSRqXmhZleezXNOyfmDwLPCTz1j2Y5tpxUK7T6WfV0ZoazbGEJwD88rU9PdL7kG5F tieW+ZseIGVqeOZ3Wp9iitqZ+agLXwFlIiOepu52MzoXBdVGbSTKfl02f7mo9blfAccI c8ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GXGxQxgfe8PHQvcuCd5BuJZbNb5Qaszh2FSV9QhQLvw=; b=W/Fcv9//3FJ9qYHDb6ev8m9Hxz8SLicTOv03RC1Az7sBuyAqP1c3Z9yBz+oePDA3Qc iv+qIGCD8qwXwuV0ZhW+TWIp9gUM0MR1sJVxqkBK54J8sdVWg9Tg2spKSra8ARcB0THh AnJ3+Idi6aju9sFhVYC4uM0MP2lcOz11kX5YsryqpuSrESdUEuH0ouPla/CiZjtGJ2eE 2AtYirAqaiQGjT+MaVcwVXH8C0srOJveij6R7kb+HsJvnTroAPyBhykEW0oQzxGbRlEw F0flasnD6exTbjrvDL4mn1Gg0DcxflpbM23M4cw00SQLwXkW0ycO+3MCoDIC6B32jeti Ilng== X-Gm-Message-State: AOAM530GZWQFV9ZxZTZZaxTFg6y47VI1NidJbGiX/bM3+BVbBPPEyVad xmdTRrLO4o8Z7HZuW/KQL/0VEfIY68C2nUVBsg2aKN/0Zioszosyaqc1Umk+aaw7Gbjd7xVCcd+ lz9Z9QlE3Zw9OZH0GhV3frw== X-Google-Smtp-Source: ABdhPJx+58U2VD/1PHWvKIzh/XGI30eACy0N0SZBSs1Xs2q3bB7912ZzyT1d90wkH8p8TIUPfBMiBPVxJ63F9DHHaYI= X-Received: by 2002:a2e:99c8:: with SMTP id l8mr11968651ljj.178.1631918388877; Fri, 17 Sep 2021 15:39:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Campbell Date: Fri, 17 Sep 2021 16:39:22 -0600 Message-ID: To: Mike Jones Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000df35a505cc389b84" Archived-At: Subject: Re: [OAUTH-WG] Adding the option to use server-supplied nonces to 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: Fri, 17 Sep 2021 22:39:57 -0000 --000000000000df35a505cc389b84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Mike, thanks for writing up the PR. Generally speaking, I think it nicely and fairly unobtrusively introduces the ability for servers to choose whether/when to use server-contributed nonces to further constrain lifetimes of DPoP proof. I've been reluctant to add something like this out of concern for introducing a lot of complexity. But this seems to do a pretty good job of it without a ton of baggage. There is one problematic technical aspect of it, however, that I think needs to be addressed before it can be incorporated into the document. Kind of a protocol compile error, if you will. The Authorization Server-Provided Nonce section uses the 'WWW-Authenticate: DPoP ... ' header in a 401 response to a token request to ask that a nonce be included in the DPoP proof in the subsequent request(s), which is sent as the value of the DPoP header. But based on the definition in this document and the underlying RFC7235, a 'WWW-Authenticate: DPoP' header is requesting that a 'Authorization: DPoP ' header be sent in the subsequent requests. The 'Authorization: DPoP ' header is only sent to protected resources. The way Authorization header is defined (can only have one in a request) and sometimes used for client secret basic auth are some of the reasons the DPoP proof is defined as separate header and not part of the Authorization header. Unfortunately, the result is that the error/challenge mechanics need to be slightly different between the AS and RS. I think the Authorization Server-Provided Nonce needs to be provided to the client in some other way. Perhaps as a parameter in the JSON of a token endpoint error response. Or in a header somehow. Or something else that I'm not thinking of. But the way it is in the PR right now doesn't semantically work. On Fri, Sep 17, 2021 at 11:04 AM Mike Jones wrote: > We all know that using proof-of-possession with issued tokens is a means > of rendering exfiltrated tokens useless to attackers. The DPoP was creat= ed > as one of the tools to prevent this. There=E2=80=99s a huge amount of ev= idence of > successful token exfiltration attacks in the wild, some of which is > referenced at the end of this message. For instance, sometimes the > legitimate user of a client is the attacker. Once instance of this is th= at > some banks have cited employees stealing legitimate tokens issued on bank > computers and taking them to non-bank computers, thereby bypassing audit > controls. > > > > When reviewing DPoP with Microsoft=E2=80=99s identity architects, they po= inted out > that DPoP as written today can still enable exfiltrated DPoP tokens to be > used by some kinds of attackers; doing so also requires that the attacker= s > exfiltrate DPoP proofs. This is possible when the legitimate user of a > client is the attacker. > > > > Preventing exfiltrated pre-generated DPoP proofs from being used in the > future requires the server being able to limit their lifetime. An > effective means of doing this is to include a server-provided nonce in th= e > DPoP proof. That puts the lifetime of DPoP proofs in control of the > server, because when a new nonce value is provided, older, possibly > pre-generated DPoP proofs become invalid at the server. > > > > The Microsoft identity server team is already internally using this > technique with the stale OAuth HTTP Signing draft. They want to be able = to > use it with DPoP for the same reasons. DPoP without this won=E2=80=99t m= itigate > the real security attacks that our systems are encountering. Note that > unless a server-provided nonce is used, what is actually being proved is > possession of a DPoP proof =E2=80=93 not possession of the proof-of-posse= ssion key. > > > > Having discussed this with some of the editors, I have created a pull > request adding the optional use of server-provided nonces to DPoP. This > will break no existing deployments. But it will enable new deployments t= o > choose to use server-contributed nonces to limit DPoP proof lifetimes, bo= th > for authorization servers and resource servers. The pull request is at > https://github.com/danielfett/draft-dpop/pull/81/. Reviews of the PR are > welcomed. I propose that we merge it and publish draft -04 sometime next > week, pending review feedback. > > > > =3D=3D=3D=3D > > > > My colleague Pieter Kasselman assembled some examples of successful token > exfiltration attacks in the public domain (and helped review the PR). > Those follow, for your reading pleasure. > > 1. Introducing a new phishing technique for compromising Office 365 > accounts (o365blog.com) > > 1. It describes a phishing attack that allows the attacker to > obtain an Access Token and a Refresh Token (which is then used to o= btain > additional Access Tokens). > 2. Operationalised with the AADInternals Tool > 2. The Art of the Device Code Phish - Boku (0xboku.com) > > > > 1. It extends the above attack and shows step-by-step how to > exfiltrate a Access Token and a Refresh Token with a similar phishi= ng > attack and then obtain additional tokens. > 2. Operationalised with AADInternals and TokenTactics > 1. DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth > Authentication Flows - YouTube > > > > 1. It shows another attack to exfiltrate tokens using phishing > techniques that exploit Device Code Flow. > 2. It includes a demo of the attack that shows how it bypasses MFA > and anti-Phishing controls and then uses the PRT to get tokens and = pivot to > other services. > 3. Tools available as open source. > 1. Requesting Azure AD Request Tokens on Azure-AD-joined Machines for > Browser SSO | by Lee Christensen | Posts By SpecterOps Team Members > > > > 1. Outlines how a Refresh Token can be exfiltrated from a Chrome > browser > 2. Operationalised with a tool called RequestAADRefreshToken > 1. Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io > > > > 1. Extracts the Primary Refresh Token through Chrome > 2. Requires executing code on the users device to interact with the > Chrome browser, executed in the user context, no elevated privilege= s needed > 3. Operationalised through ROADtoken and ROADtools. > 1. Digging further into the Primary Refresh Token - dirkjanm.io > > > > 1. Describes how the PRT and session keys can be extracted from a > device (requires local admin) > 2. Operationalised through ROADtools > > -- Mike > > > _______________________________________________ > 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._ --000000000000df35a505cc389b84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mike, thanks for writing up the PR.

Generally speaking, I think it nicely and fairly unobtrusi= vely introduces the ability for servers to choose whether/when to use serve= r-contributed nonces to further constrain lifetimes of DPoP proof. I've been relucta= nt to add something like this out of concern for introducing a lot of compl= exity. But this seems to do a pretty good job of it without a ton of baggag= e.

There is one problematic technical aspect = of it, however, that I think needs to be addressed before it can be incorpo= rated into the document. Kind of a protocol compile error, if you will. The= Authorization Server-Provided Nonce section uses the 'WW= W-Authenticate: DPoP ... ' header in a 401 response to a token request = to ask that a nonce be included in the DPoP proof in the subsequent request= (s), which is sent as the value of the DPoP header. But based on the defini= tion in this document and the underlying RFC7235, a 'WWW-= Authenticate: DPoP' header is requesting that a 'Authorization: DPo= P <access-token>' header be sent in the subsequent requests. The = = 'Authorization: DPoP <access-token>&#= 39; header is only sent to protected resources.= The way Authorization header is def= ined (can only have one in a request) and sometimes used for client secret = basic auth are some of the reasons the DPoP proof is defined as separate header and not part o= f the Authorization= header. Unfortunately, the result is that the error/challenge mechanics ne= ed to be slightly different between the AS and RS. I think the Authorizatio= n Server-Provided Nonce needs to be provided to the client in some other wa= y. Perhaps as a parameter in the JSON of a token endpoint error response. O= r in a header somehow. Or something else that I'm not thinking of. But = the way it is in the PR right now doesn't semantically work.
=


On Fri, Sep 17, 2021 at 11:04 AM = Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

We all know that using proof-of-possession with issu= ed tokens is a means of rendering exfiltrated tokens useless to attackers.= =C2=A0 The DPoP was created as one of the tools to prevent this.=C2=A0 Ther= e=E2=80=99s a huge amount of evidence of successful token exfiltration attacks in the wild, some of which is referenced at the end o= f this message.=C2=A0 For instance, sometimes the legitimate user of a clie= nt is the attacker.=C2=A0 Once instance of this is that some banks have cit= ed employees stealing legitimate tokens issued on bank computers and taking them to non-bank computers, thereby bypassing= audit controls.

=C2=A0

When reviewing DPoP with Microsoft=E2=80=99s identit= y architects, they pointed out that DPoP as written today can still enable = exfiltrated DPoP tokens to be used by some kinds of attackers; doing so als= o requires that the attackers exfiltrate DPoP proofs.=C2=A0 This is possible when the legitimate user of a client is the= attacker.

=C2=A0

Preventing exfiltrated pre-generated DPoP proofs fro= m being used in the future requires the server being able to limit their li= fetime.=C2=A0 An effective means of doing this is to include a server-provi= ded nonce in the DPoP proof.=C2=A0 That puts the lifetime of DPoP proofs in control of the server, because when a new n= once value is provided, older, possibly pre-generated DPoP proofs become in= valid at the server.

=C2=A0

The Microsoft identity server team is already intern= ally using this technique with the stale OAuth HTTP Signing draft.=C2=A0 Th= ey want to be able to use it with DPoP for the same reasons.=C2=A0 DPoP wit= hout this won=E2=80=99t mitigate the real security attacks that our systems are encountering.=C2=A0 Note that unless a server-provide= d nonce is used, what is actually being proved is possession of a DPoP proo= f =E2=80=93 not possession of the proof-of-possession key.

=C2=A0

Having discussed this with some of the editors, I ha= ve created a pull request adding the optional use of server-provided nonces= to DPoP.=C2=A0 This will break no existing deployments.=C2=A0 But it will = enable new deployments to choose to use server-contributed nonces to limit DPoP proof lifetimes, both for authorization servers and r= esource servers.=C2=A0 The pull request is at https://github.com/danielfett/draft-dpop/pull/81/.=C2=A0 Reviews o= f the PR are welcomed.=C2=A0 I propose that we merge it and publish draft -= 04 sometime next week, pending review feedback.

=C2=A0

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

=C2=A0

My colleague Pieter Kasselman assembled some example= s of successful token exfiltration attacks in the public domain (and helped= review the PR).=C2=A0 Those follow, for your reading pleasure.

  1. Introducing a new phishing technique for compromising Office 365 accounts (o365blog.co= m)
    1. It describes a phishing attack that allows the attacke= r to obtain an Access Token and a Refresh Token (which is then used to obta= in additional Access Tokens).
    2. Operationalised with the AADInternals Tool
  2. The Art of the Device Code Phish - Boku (0xboku.com) =
    1. It extends the above attack and shows step-by-step how= to exfiltrate a Access Token and a Refresh Token with a similar phishing a= ttack and then obtain additional tokens.
    2. Operationalised with AADInternals and TokenTactics<= /u>
  1. DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authenticatio= n Flows - YouTube
    1. It shows another attack to exfiltrate tokens using phi= shing techniques that exploit Device Code Flow.
      2. It includes a demo of the attack that shows how it byp= asses MFA and anti-Phishing controls and then uses the PRT to get tokens an= d pivot to other services.
    2. Tools available as open source.
  1. Requesting Azure AD Request Tokens on Azure-AD-joined Machines for Browser SSO | by L= ee Christensen | Posts By SpecterOps Team Members
    1. Outlines how a Refresh Token can be exfiltrated from a= Chrome browser
    2. Operationalised with a tool called RequestAADRefreshTo= ken
  1. Abusing Azure AD SSO with the Primary Refresh Token - dirkjanm.io
    1. Extracts the Primary Refresh Token through Chrome
    2. Requires executing code on the users device to interac= t with the Chrome browser, executed in the user context, no elevated privil= eges needed
    3. Operationalised through ROADtoken and ROADtools.
  1. Digging further into the Primary Refresh Token - dirkjanm.io
    1. Describes how the PRT and session keys can be extracte= d from a device (requires local admin)
    2. Operationalised through ROADtools

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke

=C2=A0

_______________________________________________
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. --000000000000df35a505cc389b84-- From nobody Mon Sep 20 05:52:44 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D993A08FF for ; Mon, 20 Sep 2021 05:52:43 -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_MSPIKE_H2=-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 (1024-bit key) header.d=armh.onmicrosoft.com header.b=Kxbben2G; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Kxbben2G Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oERvEf9tIoWb for ; Mon, 20 Sep 2021 05:52:37 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30056.outbound.protection.outlook.com [40.107.3.56]) (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 3A12D3A08FD for ; Mon, 20 Sep 2021 05:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TDBJMPZbEv75Wx1T5Piy7MKRBkA7UlWU2utpLTBviao=; b=Kxbben2GWkTyG9r9iD6wUbJUyDvq2qxRMTRso/ZHiesl9O0PD6FqV9YmnlCutrNKZfb0CSTgFr5zGWLpmnaj5AhfEKZU3OnFb+XyGshZ9sRCa/PwadsogFIyzlQ9jzzdv8Va0OuLdhnhIu331CJXKY1ClBllYgCCp/sybqQgl5w= Received: from AS8PR05CA0003.eurprd05.prod.outlook.com (2603:10a6:20b:311::8) by AS8PR08MB7249.eurprd08.prod.outlook.com (2603:10a6:20b:340::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16; Mon, 20 Sep 2021 12:52:30 +0000 Received: from VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:311:cafe::ff) by AS8PR05CA0003.outlook.office365.com (2603:10a6:20b:311::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16 via Frontend Transport; Mon, 20 Sep 2021 12:52:30 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT032.mail.protection.outlook.com (10.152.18.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14 via Frontend Transport; Mon, 20 Sep 2021 12:52:30 +0000 Received: ("Tessian outbound f1898412aff1:v103"); Mon, 20 Sep 2021 12:52:30 +0000 X-CR-MTA-TID: 64aa7808 Received: from f5aff363c5d4.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9477F7A8-6981-4A05-8C4D-9716B0E3ED14.1; Mon, 20 Sep 2021 12:52:24 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f5aff363c5d4.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 20 Sep 2021 12:52:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fRUEoTF/X6qbuBvgqqZjt1RVqPyEzjhalQmUEFovNCX5Hrzj92o7fvbuyUziL/2S67bBZ34P+XgNZ3CfVgBvp7nbpcziwqBKV4lbWI3+Wl+0YSQzA4xRW+FcHpchVqx069VTDAQOsM6aUKceVI+TtZurf8TIlIomMccKqNhpDcd7qMq3Oe1RpgpGbrBnA+KF+CI8uzFuxKbGLNFZQgTStB9JYnEJo4QWSfVEQfZyWZAbMtwHtWEjhm/YyvaSn5TTrlhors1Tbf6w6RXBNbo/3xeD1svX5LSpWKPyHhNWoO1mF46pcaG20YHf8vGWfqrjPiM3oMv4BlQdH13Zusn7hg== 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; bh=TDBJMPZbEv75Wx1T5Piy7MKRBkA7UlWU2utpLTBviao=; b=K0xgMK00ByV+j3mbBQJevqVMhBCnQoCUWcGlT7Ptbb89gUllMN8D1lYicIHWdp5F5lalMTY0jqCbNJY9uwAA2t5GNHtd3LnfS/OQ6wsJahaZkOtumaZc0RdIhSiHfy89dW40ArnfpyHFuD1xYekvEKCtHtHpq4cumY5IGS6l4WRnUh3sXXsgESKC0JCoCwpYHkuH/bQ0RZJ8yePhbkWl41TJcH2WoaDp41OGQ+yx9Nh4kNNMi/3eqJejHM83LOrkyu8QAwyK0a4Ld2bt3Em4WOBKAg2W+oITXNy9voXqoI1RgCZV/kEGLS/Bj7H/bn7WWeR01Ox5sqJk6+Yx2Fm+hw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TDBJMPZbEv75Wx1T5Piy7MKRBkA7UlWU2utpLTBviao=; b=Kxbben2GWkTyG9r9iD6wUbJUyDvq2qxRMTRso/ZHiesl9O0PD6FqV9YmnlCutrNKZfb0CSTgFr5zGWLpmnaj5AhfEKZU3OnFb+XyGshZ9sRCa/PwadsogFIyzlQ9jzzdv8Va0OuLdhnhIu331CJXKY1ClBllYgCCp/sybqQgl5w= Received: from DBBPR08MB5915.eurprd08.prod.outlook.com (2603:10a6:10:20d::17) by DB9PR08MB6395.eurprd08.prod.outlook.com (2603:10a6:10:254::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Mon, 20 Sep 2021 12:52:23 +0000 Received: from DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::89bf:bcfa:58b5:64b8]) by DBBPR08MB5915.eurprd08.prod.outlook.com ([fe80::89bf:bcfa:58b5:64b8%9]) with mapi id 15.20.4523.018; Mon, 20 Sep 2021 12:52:16 +0000 From: Hannes Tschofenig To: oauth Thread-Topic: New Doodle Poll for OAuth Virtual Office Hours Thread-Index: AdeuHjdp8yxpL6V8Sz6vBjJdKdoRpQ== Date: Mon, 20 Sep 2021 12:52:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 168705A658A24A43BC4ABFC42FA7500A.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: ee8d82bb-6142-4896-ac03-08d97c3581ed x-ms-traffictypediagnostic: DB9PR08MB6395:|AS8PR08MB7249: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:3044;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: nzgLS6StBjxlX8l9Tw1YdpWWbcpYQkL+bC9Hpf+OS53tKPc6ZvE7XVj6x6jUMRVp0JtGiFZQd6O3naB8noG7INyLgfkYrGFyjki1VxCjFPWo3a1VMq4dJnDTc6wc0TyQGZ5s3BdCaZy6O1dCSHwixjFHYEoWQv7e8/6IyBAIzJ4YCwFJuSMm+OO3D/+hRFnt5mCiEYrmHDkvwB4TGR+ymfuASqKtdKaewrKg4eFuRHnOycfCnN1d+rZ/nFAI21iaDEKXyLj3k4IVt+UeZ0Hz0s+1zNUFuQ2qTFivmpzCKmtR7KDUDM5NPyHS5QX47pZ090295nXI5XU5oGXHCi7FsAkn/U2TFNyt7Imkd99l2UO0tRGaZGHWzzHS00DbyWdMnNzmMVBgbwMGmhyykXP/pK+WdFOMx4PfujbX6Wc1KeLskW51lfKjbft06rwax5d3lmv1yiZDbo34sFgPJ8X/2H7bLaGhaHBD9TtDHvHq1OX8ur8zIneXn7JyrinLE68hk5daSEO71A/LDKDxqy/17kAF+69dXNWO4C25Qh8nIJ+aXKeM675oyMg29wsaT1tAvyXkHklp+xF5KYgMwlYWbWK8d1TJerYFJ6bhTNcVffcxibSUs+bcFF3biUFUk0Hd/9P0ecOxSpxiNQL3TChmwsaCWp5RXFrcrXTmNXYPmkI3ZYXFv5GTk70BZ8LaKItKPkICQ3JanhcZXK+DottLjBJSTh5AuqD9DC8v/4x5PKomRtJP1CQIa1ZVR7cpR8I8iIq6fnyO+3kw4Lyv03GejQPNku/Gu3tf96EqOhESDjM= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR08MB5915.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(396003)(366004)(346002)(39860400002)(64756008)(66476007)(38100700002)(66556008)(66946007)(966005)(478600001)(66446008)(4744005)(9686003)(166002)(26005)(55016002)(71200400001)(122000001)(76116006)(6506007)(86362001)(186003)(6916009)(316002)(52536014)(83380400001)(2906002)(8676002)(38070700005)(5660300002)(33656002)(8936002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR08MB591587ED5974C74015B2DD53FAA09DBBPR08MB5915eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB6395 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: c8fbdefb-73d5-41ef-b7ef-08d97c3579a5 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M8Sqwdce0r65QA0U49NcUdKd+U9hSWMxC14SICDiOVR2tJYpiclwzURhVptjLS+bKmT9SJkHjpEYgFI+2fWY9lzNnUST+n3iNX1TBL1jDscMEjMTHPjZRoSh0El8ArXJgui21Cn9Dww5+SouXDYMre2EdpWKVFTQMqh/wX1jd6jy0Pz0dKIXZ0QGHauBDf84++ZM2VQJ2sCaVJHrlMN6rXxR49L3vC2/V9c21Icktj4rYTKQ6AQ2SHTkxXy4JyC3vIWaCy5Ej22yz+xKUW0W7U+8HBjUphJOzUSFZPkPfoZnPra3V/YzpoUukPc4JFai04H0EETgYG5ziuwn+48TsJmWQXV6HoYUutTD1aqoQK9vx0uTjYdVbPOm0SZUINfGAx9Y4i1gRjGVncwpdAT/MTUbnh+yzq+JzRjbyGBMlJDMYd7Z5cxv2KSKN8NUOx57em0xU3FY5Q8JNsPFDp8AfAfR+X5lyul1h+VyQjh7o0ixxER8k0exd7pabZuVg9/52XPhsmQQFA5EC/uvJhGWOp6+kL3mNYBp3E+tgMqyi4CeapQ9pC+IjvYt8aIpmHtkq306pkVah2yBz+S0xJEPPyLcJ5m5be0TpCt7evug+AdfIqwpdDdjERAHawFZ6GpytJM51OklduuZgRSokKGnvwfaGfFzZ2uCcZJiq/W3aOlCTMqC1yF7vvb8qu0HWuP+iNKqxiFwJq+PzC5DguUmaY3nQbds0pWjJN0j179HaXUegT0DjBsd6r91nfXobOAsPmjlS7ZfMuVQ5f6gqB1gFvFblJOqzKBqNnHPode+xlg= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(376002)(396003)(346002)(136003)(39860400002)(46966006)(36840700001)(70206006)(86362001)(82310400003)(36860700001)(966005)(82740400003)(47076005)(5660300002)(8676002)(70586007)(6916009)(83380400001)(316002)(6506007)(166002)(52536014)(8936002)(478600001)(7696005)(81166007)(336012)(2906002)(55016002)(9686003)(356005)(186003)(26005)(33656002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2021 12:52:30.3514 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ee8d82bb-6142-4896-ac03-08d97c3581ed X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7249 Archived-At: Subject: [OAUTH-WG] New Doodle Poll for OAuth Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 12:52:43 -0000 --_000_DBBPR08MB591587ED5974C74015B2DD53FAA09DBBPR08MB5915eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all We are running a Doodle poll to find suitable times for our bi-weekly OAuth= office hours. Here is the link: https://doodle.com/poll/2tf58dmmhvgi6rrt?utm_source=3Dpoll&utm_medium=3Dlin= k Ciao Hannes & Rifaat IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_DBBPR08MB591587ED5974C74015B2DD53FAA09DBBPR08MB5915eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 

We are running a Doodle poll to find suitable times = for our bi-weekly OAuth office hours. Here is the link:

https://doodle.com/poll/2tf58dmmhv= gi6rrt?utm_source=3Dpoll&utm_medium=3Dlink

 

Ciao

Hannes & Rifaat

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_DBBPR08MB591587ED5974C74015B2DD53FAA09DBBPR08MB5915eurp_-- From nobody Mon Sep 20 11:04:30 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47043A0F3D for ; Mon, 20 Sep 2021 11:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 sCEqfgupMXEL for ; Mon, 20 Sep 2021 11:04:23 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A296C3A0F41 for ; Mon, 20 Sep 2021 11:04:23 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id i23so32204838wrb.2 for ; Mon, 20 Sep 2021 11:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Etx+fa6YVR8rFp8FoJ7NlLqRfBow17KASvtqKs2PQFE=; b=Y5kIzsg4a30Ni4UEi1M0HUvFNJXsPlR06h/4yOR0+ebMfCwB808axmSihkFdVhC9H3 S2FPfzjgaz4UMrzGDl0V3awVo8wv+93qibQFnPQInkpzqD0bRz7oiBGdDgXXBL+rOWc7 dTUEbCGr6NTCQrPR8CdYdrkk2FIZmbXHG/8VeEJH21qLr6OjzwP6pHCVQO6iVXxOTWjx BxSI6KDzVQnU6HTOFafmj/yCkETBvUHyczwwk3Q1mWP85dbt5SN3GMHl/hjcJddPXZ+V s2flMFARHXA/y9QJu9s30OV/fsOK67BenQl1FeIRgCO9Attsrc4dT6rP9uce0Mx/hhMf CGQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Etx+fa6YVR8rFp8FoJ7NlLqRfBow17KASvtqKs2PQFE=; b=cHc0b/SQDtDlN23oLj70laqlVamH9857hBY+9u1NGGlK5TtEriEf2HWYW3KgNqKrXy GWkJ8PejgyqqxLeVik4dPB1Poz4bMxaf9TFMjMqrVKcnty3iVAp63ZbqXmifga9dGw0e fuZYn8uEYYAoRAz+A6zKu/8NVVBJ0brAxZLZLbIlI7jy/eGKoyV7IYlhBAgf2QE02V6s ZL2q+8vQ5x8yVvhvjz+RxW4g09bK9wnA3CL4SQpFhDx7ifrCUg9wjglPMUr4xZ+bb0U0 VQ2dmZMVv+Zg5bMZRKg6pFhBp9txjtE6ke86BsKVkTl7UIvk1MiLsJYIMQG4f/USQqdb JvOg== X-Gm-Message-State: AOAM531goFlVkwuak61klcKto7eFL7hmpH4mjAajcwllZupQoxCXk7Pk WooLzlhJvxPmelgSkyrOu+DsajcijJ/RJDqy83U= X-Google-Smtp-Source: ABdhPJymY+cBufKBlTOWI/m053n5pScB21y8xswJW6lwBIMYftsoLUAtJMCmhMRJMcdrPhPEg86IUx442ETmqmepoOE= X-Received: by 2002:a1c:4d7:: with SMTP id 206mr358150wme.158.1632161061878; Mon, 20 Sep 2021 11:04:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 20 Sep 2021 14:04:10 -0400 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="0000000000004f3ec005cc711c3f" Archived-At: Subject: Re: [OAUTH-WG] New Doodle Poll for OAuth Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2021 18:04:29 -0000 --0000000000004f3ec005cc711c3f Content-Type: text/plain; charset="UTF-8" Just to add some color to this request. The goal is to find a new timeslot for our biweekly *OAuth WG Virtual Office Hours *because we are having some issues with the existing timeslot. This new timeslot will also be used to host the *interim meetings *which we are planning to start in the coming few weeks. Regards, Rifaat & Hannes On Mon, Sep 20, 2021 at 8:53 AM Hannes Tschofenig wrote: > Hi all > > > > We are running a Doodle poll to find suitable times for our bi-weekly > OAuth office hours. Here is the link: > > https://doodle.com/poll/2tf58dmmhvgi6rrt?utm_source=poll&utm_medium=link > > > > Ciao > > Hannes & Rifaat > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0000000000004f3ec005cc711c3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to add some color to this request.

The goal is to find a new timeslot for our biweekly OAuth WG Virtual Of= fice Hours because we are having some issues with the existing timeslot= .
This new timeslot will also be used to host the interim meet= ings which we are planning to start in the coming few weeks.
=
Regards,
=C2=A0Rifaat & Hannes

<= /div>

On Mon, Sep 20, 2021 at 8:53 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all

=C2=A0

We are running a Doodle poll to find suitable times = for our bi-weekly OAuth office hours. Here is the link:

https://doodle.c= om/poll/2tf58dmmhvgi6rrt?utm_source=3Dpoll&utm_medium=3Dlink=

=C2=A0

Ciao

Hannes & Rifaat

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--0000000000004f3ec005cc711c3f-- From nobody Tue Sep 21 00:17:26 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26953A0AFE for ; Tue, 21 Sep 2021 00:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=lodderstedt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2A7qW-iWkqc for ; Tue, 21 Sep 2021 00:17:19 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F5E3A0AF9 for ; Tue, 21 Sep 2021 00:17:19 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id t8so36248242wrq.4 for ; Tue, 21 Sep 2021 00:17:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:mime-version:subject:message-id:date:to; bh=npO5dDJ6Xu6oSt3WpUJZrwH7vYeY1Qf18SXyRxGEKTA=; b=e4rpoFmNV+ms6b8fv9b+ZuRt3G8oDdQCnVEbn6UpqfArFB0ut2CKvLrLJGlpf1va55 KjTLWd5r5eZAjG0oQgamNRTdZdcQ0WL75jKA3Q/sGQpXdxQvcpW3zomhTYYqwW4ksRFa 8+oNqRTEOLTfPBMRlczhNFrD8lPufTmqqkGTv0ulVy8u0pP6xqKpEV4ICEVd3ggmCLW1 f5HNZFwvUnsu/j2cEMfKo/V+7onXEhmcnkunH9rDsBafk20/bSge73JVNcA3xXy45FqZ M2XVZw8kuShdvOs/sZ6+LHSzBJ06ZG3tbPIlfWDp7XR1vC+bIZ85qeGogbUC/zYhWEL/ I6+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=npO5dDJ6Xu6oSt3WpUJZrwH7vYeY1Qf18SXyRxGEKTA=; b=26spmLujm6wa7X9UfSvbhedWxzTPfsRmAdZpsPfIXNSOzXBXPr0qW/VDYsfs0AUqAS 4WsZPnVEHPO6DXkBAtWjI/b6+3scEUcQNJ4KN/1OuGNdKiy+cNeytw4PdFZhLyppz02E o/givqwY1jkIMSrxjb+2aCrHlJ4Ta6kP1j+PjGa3DLrhQy6dtyrhjXGL9aXW23MwEoTO m8mU6Y6jsYJz/r+R/M0o4L7CDBMm8In7znmy0M313FEvFzsnnRxJlnKJ8I8VdFsXcnlW v/N7Q6JQvJj1ww5CHSePluGe06Tb+/0iOGS0p+JQ1kNpyWrlC3iCQVT5SIpGJWtMlyHT 15Ag== X-Gm-Message-State: AOAM530vC2VCMqzSYUEJtjGz6AwfsJly2cQebTnEs43kNvuAr2F2Cobx IxOfI3xhRuUiYfba6hUYTkrgYrhg8SukmJOu X-Google-Smtp-Source: ABdhPJyGTSUMIGgU/1+jkirgRL2Q24/dfu2Kvf+8pW9/8j1qqxajDV4unC2mSNvZyJzR9dxzabWfrQ== X-Received: by 2002:adf:f904:: with SMTP id b4mr32981374wrr.403.1632208637177; Tue, 21 Sep 2021 00:17:17 -0700 (PDT) Received: from smtpclient.apple (p200300eb8f1c62b7a59b7dda11bed7a1.dip0.t-ipconnect.de. [2003:eb:8f1c:62b7:a59b:7dda:11be:d7a1]) by smtp.gmail.com with ESMTPSA id w14sm18175271wro.8.2021.09.21.00.17.16 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Sep 2021 00:17:16 -0700 (PDT) From: Torsten Lodderstedt Content-Type: multipart/alternative; boundary="Apple-Mail=_8712796C-8C4A-47FC-98C8-4D94A530CB29" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-Id: Date: Tue, 21 Sep 2021 09:17:16 +0200 To: oauth X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: [OAUTH-WG] GAIN Digital Trust X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2021 07:17:25 -0000 --Apple-Mail=_8712796C-8C4A-47FC-98C8-4D94A530CB29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 as requested in the OAuth office hour yesterday, I would like to share a = link to the GAIN site. At https://gainforum.org/ you can find the = whitepaper written by more than 150 experts suggesting to built a global = network of identity providers. The network shall be open to anyone able = to provide assured identity data. The envisioned architecture follows = the patterns established by open banking, i.e. every service provider = can offer its services directly to relying parties via a standardized, = interoperable API. The network will facilitate discovery and trust among = the parties. In the next step, we want to build a Proof of Concept to evaluate and = demonstrate the feasibility of the approach.=20 If you want to know more or want to contribute just drop me an email.=20 best regards, Torsten.=20= --Apple-Mail=_8712796C-8C4A-47FC-98C8-4D94A530CB29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi all, 

as = requested in the OAuth office hour yesterday, I would like to share a = link to the GAIN site.

At https://gainforum.org/ you can find the whitepaper = written by more than 150 experts suggesting to built a global network of = identity providers. The network shall be open to anyone able to provide = assured identity data. The envisioned architecture follows the patterns = established by open banking, i.e. every service provider can offer its = services directly to relying parties via a standardized, interoperable = API. The network will facilitate discovery and trust among the = parties.

In = the next step, we want to build a Proof of Concept to evaluate and = demonstrate the feasibility of the approach. 

If you want to know more = or want to contribute just drop me an email. 

best regards,
Torsten. 
= --Apple-Mail=_8712796C-8C4A-47FC-98C8-4D94A530CB29-- From nobody Tue Sep 21 05:14:19 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F883A0B55 for ; Tue, 21 Sep 2021 05:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 CJtuzcPWJA0a for ; Tue, 21 Sep 2021 05:14:13 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BF53A0B6C for ; Tue, 21 Sep 2021 05:14:13 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id u18so36761236wrg.5 for ; Tue, 21 Sep 2021 05:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kZw0pfVIMyPn5iueb/8uhjB9l+DRuhtFuqhd0FTVn+Y=; b=Dcqqxckau6uPGC2ksSaWvt72hEN77cuhZ54F40swMW2+KK8kMtLcTtiPNjQSzy1OYd jfauP42NLjOUU9oyInJRmBNoAiHnz6lHHzHy1Gsb2rPaVy18eauSu2Gco0c4yCwQRqDE uSE6SqlJ3Y9IgRgtGDOreRHGdUNeHzDKvEAG4IPOQNYTf78EJNCVL92rFzIGHpGJxq4p 6MSvUez9a/oeUYeYhHId6RKkcZPNMsdhHb83k4VJjUL9ND4PxLXCP5EIcq0EFOkdy/p9 6wveiwZ/UwPPQ3t3wN4djsiqHjD0KuTKx1i+IbLPvAmAi/6tSgRF9pgC4loZN4amdNtS H8sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kZw0pfVIMyPn5iueb/8uhjB9l+DRuhtFuqhd0FTVn+Y=; b=A/2VA5dD3Wa4OprqjvG/sEH0eDitAzFbwxMMBMIRpPXxNaVeVENIPH0ksj6Tt7kyrm 2K6E2c7w87b6QOWofDPYr8GrR7Q5/iRWS6k53ghUXpgujIIh7k2e9T2dzbGhI5ossZNc vSG2gxiqidLUXQtcF7cEu1BYTeFKyTouKFMKju6E6AvoO7yhinDCldU2kVUYWj0N7TP8 ztaVw7ivUtnuN17tln1sdWEQSnZnTHBqBTMxtEmOG9GXaveltkwJp0q4pilPoi9ih5gV fieKOI4WW0ExBGyyxYzrXhhvpytJuGcw27NLEJPZbskO74oJJv8jWGPGi9vM4srPifg7 rO4Q== X-Gm-Message-State: AOAM532lg7Ol63LUqqWqojDwxs0dJR++EoyTe2Cvadv716hzGwJe0i+I 1Zvz0L9lStrg432d1NaeTLvoI4PEQogYIlkVnR0RBWvq X-Google-Smtp-Source: ABdhPJwPNLvedtW6X4pLmwuGHiY+Sq1nAaEMtUuBhEhFLFzug+CY6W9XkEyaFBj2W1XLabAeQlBKmPv5LyavbWFaWo4= X-Received: by 2002:a1c:f019:: with SMTP id a25mr4367229wmb.96.1632226449375; Tue, 21 Sep 2021 05:14:09 -0700 (PDT) MIME-Version: 1.0 References: <7C9A0383-0DC8-4D78-8186-75B7B229414D@ietf.org> In-Reply-To: <7C9A0383-0DC8-4D78-8186-75B7B229414D@ietf.org> From: Rifaat Shekh-Yusef Date: Tue, 21 Sep 2021 08:13:58 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000b5456605cc8055b1" Archived-At: Subject: [OAUTH-WG] Fwd: IETF 113 (March 2022) venue update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2021 12:14:18 -0000 --000000000000b5456605cc8055b1 Content-Type: text/plain; charset="UTF-8" FYI ---------- Forwarded message --------- From: IETF Executive Director Date: Mon, Sep 20, 2021 at 8:08 PM Subject: IETF 113 (March 2022) venue update To: IETF Announcement List Following local advice regarding the situation with COVID, the IETF Administration LLC has concluded that IETF 113 (19-25 March 2022) cannot be held in Bangkok and must move to an alternative, yet to be decided, venue. The search for this alternative venue is well underway with options being considered across all IETF regions. In anticipation of the COVID situation continuing to restrict and reduce travel, we are looking at venues suitable for a meeting with 50% the level of onsite participation as before. We expect to announce the new venue late this year. Please free to contact me directly if you have any questions or comments - exec-director@ietf.org, -- Jay Daley IETF Executive Director exec-director@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --000000000000b5456605cc8055b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI

---------- Forwarded message ---------
From: IETF Executive Director <exec-director= @ietf.org>
Date: Mon, Sep 20, 2021 at 8:08 PM
Subject: = IETF 113 (March 2022) venue update
To: IETF Announcement List <ietf-announce@ietf.org>


Following local advice regarding the situation with COVID, the IET= F Administration LLC has concluded that IETF 113 (19-25 March 2022) cannot = be held in Bangkok and must move to an alternative, yet to be decided, venu= e.=C2=A0 The search for this alternative venue is well underway with option= s being considered across all IETF regions.=C2=A0 In anticipation of the CO= VID situation continuing to restrict and reduce travel, we are looking at v= enues suitable for a meeting with 50% the level of onsite participation as = before.=C2=A0 We expect to announce the new venue late this year.

Please free to contact me directly if you have any questions or comments - = exec-director@i= etf.org,

--
Jay Daley
IETF Executive Director
exec-director@i= etf.org

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--000000000000b5456605cc8055b1-- From nobody Thu Sep 23 16:23:40 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C53A0637 for ; Thu, 23 Sep 2021 16:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=backbase.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5anrxedw8_P for ; Thu, 23 Sep 2021 16:23:33 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117283A060D for ; Thu, 23 Sep 2021 16:23:33 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id t10so32676974lfd.8 for ; Thu, 23 Sep 2021 16:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=H0YPbI0EKRfpQvkEchL6PNnKZriG5lPvTyWudjF9w1U=; b=YtyY2YFqEMegmzUvFcAgpcs6YefxGNWUCEtM0hLH6320tmpUU8lscFWbk9p5xBOnF2 Tzqvf1y8niSNg1e/vlxm2DbTgFaZ2k2h8ra15QSi2/VYU37R4jkqzmhN7efd0d8ZaSuZ W7002f82HO2IuOWpmSFegG+dSXbGbypllnpffFZRuo6L9iHQzbOa+UwES5Hfxb8xnLUS mdhKJq8/H/EOb1Sr2xAsJp2CwdzL7OlEdPy1IeSS6+kjEUQ6BPjhC6uIEzj4xckcrTXB 7ODS3nuTk/GWlqvXesv+jW/zk2z4zOvLcb/zqwg5+tbsGVvZQ8xK7SkNSiE2Ulx44ZdX LBZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=H0YPbI0EKRfpQvkEchL6PNnKZriG5lPvTyWudjF9w1U=; b=HSXjvUNf/P08nY82OD5QFb48m9+2walZ9s2GWE+hdp9LtuPgsX07FLWGG/jb1f1Za3 ud9m+tH07weMGzaIDguPHNsShUNUYpGU1P1TeEXQm2/YS+5nLe6vdjG7DAV3FwUYl4ht uscOkjUDXOuE51Gr9zX+w9eyQADzezf/ZF0MhdkI9vdG5HbdX8tgUtev4LkXNr4sXYME tTm721Z6deOBM7epW4PGm7VYU6R6DKjXFhPm3v97eMHUKCm8BYO3cfrVo73rc2BGrbiN caNXq3K75OnCykdjB2ApOZXByUaX+h9Q3ss1GLvMiXD8D1uL4rsMJb2MdFqsIOBKry+g NpEQ== X-Gm-Message-State: AOAM532M3lbRFbupcOJ6wyQAG8/JjsI22lDlPfQbYqTeU9QDs9w8HJC8 NDMVBo5UjlkK/VOBpH/l34hTXlTVZocFFPM11TzoEYzZXQSYwA== X-Google-Smtp-Source: ABdhPJzkcLaHVGHn+GoxPECNSHoY0SOSg4QVm8B32QlhNyY9OjYMR1jsRB+7gMsohrBTzyFKz1h11w6tiKJzftJiumI= X-Received: by 2002:a2e:6d12:: with SMTP id i18mr8334051ljc.481.1632439410742; Thu, 23 Sep 2021 16:23:30 -0700 (PDT) MIME-Version: 1.0 From: Dmitry Telegin Date: Fri, 24 Sep 2021 02:23:20 +0300 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000031fc5005ccb1eb39" Archived-At: Subject: [OAUTH-WG] RFC 8705 (oauth-mtls): RS error code for missing client certificate X-BeenThere: oauth@ietf.org X-Mailman-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, 23 Sep 2021 23:23:38 -0000 --00000000000031fc5005ccb1eb39 Content-Type: text/plain; charset="UTF-8" >From the document: The protected resource MUST obtain, from its TLS implementation > layer, the client certificate used for mutual TLS and MUST verify > that the certificate matches the certificate associated with the > access token. If they do not match, the resource access attempt MUST > be rejected with an error, per [RFC6750 ], using an HTTP 401 status > code and the "invalid_token" error code. > > Should the same error code be used in the case when the resource failed to obtain a certificate from the TLS layer? This could happen, for example, if the TLS stack has been misconfigured (e.g. verify-client="REQUESTED" instead of "REQUIRED" for Undertow), and the user agent provided no certificate. Thanks, Dmitry --00000000000031fc5005ccb1eb39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From the document:

   The protected resource MUST obtain, from its TLS impleme=
ntation
   layer, the client certificate used for mutual TLS and MUST verify
   that the certificate matches the certificate associated with the
   access token.  If they do not match, the resource access attempt MUST
   be rejected with an error, per [RFC6750], using an HTTP 401 status
   code and the "invalid_token" error code.

Should the same error code be used in the cas= e when the resource failed to obtain a certificate from the TLS layer? This= could happen, for example, if the TLS stack has been misconfigured (e.g. v= erify-client=3D"REQUESTED" instead of "REQUIRED" for Un= dertow), and the user agent provided no certificate.

Thanks,
Dmitry

--00000000000031fc5005ccb1eb39-- From nobody Thu Sep 23 20:00:38 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216403A0DCA for ; Thu, 23 Sep 2021 20:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=backbase.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpYTt-6tC_ow for ; Thu, 23 Sep 2021 20:00:31 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BDB3A0DC1 for ; Thu, 23 Sep 2021 20:00:31 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id u8so33530703lff.9 for ; Thu, 23 Sep 2021 20:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GkOwOzMsPRRn+k4oyUG9aTX75iO3Q6BycTt9BnpRCnA=; b=LhMzGY/wtzW/8rOtk0Aqhlh7cl5bIcHZCeLv7aGRxJZSg03Ll42tbVpBK4eC2CxJIP 6x2OTkD4/lf7/rDsxrud1vdc8I4Po5CJoGB5Ge77ZATtLOH9QjyX6NgeykLWGuF2HwX6 L7ckmVuoPQq6p4yKNq0hDFQa7ivV1esYXSBQNu9MFdqKN9rveE1XP2F2mG5LwyGNzwvr TzLzT1PyufHdDXCLTvTFJKgkEEL2X9AudGD03j53UInBfCUa8O3JA/1C+NwKY5hWfKzA tQRMDNMygQPq4+iahr7ZKuvUzL+Ff0vmg7OErqu1A1fCNzPt6vRM8yxBxvSimY5Wp18I 1K+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GkOwOzMsPRRn+k4oyUG9aTX75iO3Q6BycTt9BnpRCnA=; b=pzR/ErBq4VSLEG8DUdfoAcq05JDlzexaCfhxyRDA+df3CrgjRCDkrhR2bGt9gu80rP 2g/z4U4YFEmomUE6MsmAVLKRIUbEH2uXsnCP6QZu7mEwxJVxsyNkNRndTDiC5SQMJZps RiwDopUVfNfcuUD8Fd54NzarVi7oDbTI+e6Tx747LDNJ5ZMZt+JU+KaVWlmAX7l6zo8B GgluXg3eKm26DqxXRGBg0Pv6tKmZg4H9EYE2j8tElQaGSMQuzcibpMmjzyJw1B0Y8jsv tlbDS5zvMgy4ZSW3ZyP/7UFbxMntTRh7R+5KrQwH4oZpAGcRFGIvz7WVBx+5zn0NqQdz HAkQ== X-Gm-Message-State: AOAM533f+rWAHVQ6LoytPWHfzYOlqwD86JinuMwoVQoCeD7rkrY05h2t 3wE21LEobyAHdd6K3PCgRpp4YtQbRBhQT6mmHt1kfeNEoHLTkfcM3QXMOVdmVLDBVgM59mGlii6 FAseXkRoFVQCdzOZ+Ot5Q X-Google-Smtp-Source: ABdhPJwSMSSh8sgRZrJDviy1LKRLoqLSKFL8NhzQQv2hxLwSaqt3Un4v5iTUBvt6sFipeU2PgIQ/vlNc2NXpnhUKfDA= X-Received: by 2002:a05:6512:3191:: with SMTP id i17mr7111439lfe.381.1632452428702; Thu, 23 Sep 2021 20:00:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Telegin Date: Fri, 24 Sep 2021 06:00:18 +0300 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="00000000000020427f05ccb4f3ae" Archived-At: Subject: Re: [OAUTH-WG] [DPoP] Protected resource access and invalid DPoP proofs X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Sep 2021 03:00:37 -0000 --00000000000020427f05ccb4f3ae Content-Type: text/plain; charset="UTF-8" Hi Brian, Just wondering if there's still a chance for this to be addressed in 04? I could try preparing a draft PR if that helps. On a related note, are there any recommendations on the contents of the "error_description" WWW-Authenticate attribute? For example, our prototype DPoP implementation for Keycloak recognizes the following error conditions: - DPoP proof decoding failure - Invalid DPoP signature - Invalid or missing "typ" in DPoP header - Unsupported DPoP algorithm - No JWK in DPoP header - No public key in DPoP header - Private key is present in DPoP header - DPoP mandatory claims are missing - DPoP HTTP method/URL mismatch - Malformed HTTP URL in DPoP proof - DPoP proof has already been used - DPoP proof is not active - No access token hash in DPoP proof (when used with an access token) - DPoP proof access token hash mismatch (same) Would you recommend to a) provide detailed info (above) in error_description, b) provide generic "DPoP proof missing or invalid", c) omit error_description? Thanks, Dmitry On Tue, Aug 10, 2021 at 12:58 AM Brian Campbell wrote: > Hi Dmitry, > > I think you are right that it's probably worthwhile to allow for a > distinction in a protected resource error response. I'm inclined to say > that a new error code such as "invalid_dpop_proof" to use with the 401 > response containing the DPoP WWW-Authenticate header is the most > straightforward way to accommodate it in the document. I'll look to add > that, probably somewhere in section 7 > , > in the next draft revision. > > > On Thu, Aug 5, 2021 at 8:50 AM Dmitry Telegin 40backbase.com@dmarc.ietf.org> wrote: > >> Hello, >> >> When a protected resource is accessed using DPoP proof + DPoP-bound >> access token, either of those could be invalid. Should we make distinction >> between these two cases? I.e. should the response always be a 401 >> Unauthorized with WWW-Authenticate: DPoP ... error="invalid_token"? or >> could we use error="invalid_dpop_proof", similar to token request? or maybe >> even 400 Bad Request? >> >> Regards, >> Dmitry >> >> _______________________________________________ >> 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.* --00000000000020427f05ccb4f3ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

Just wondering if = there's still a chance for this to be addressed in 04? I could try pre= paring a draft PR if that helps.

On a related note, are there any recommendations on the contents of the=20 "error_description" WWW-Authenticate attribute? For example, our= =20 prototype DPoP implementation for Keycloak recognizes the following=20 error conditions:
- DPoP proof decoding failure
- Inval= id DPoP signature
- Invalid or missing "typ" in DP= oP header
- Unsupported DPoP algorithm
- No JWK in DPoP= header
- No public key in DPoP header
- Private key is= present in DPoP header
- DPoP mandatory claims are missing
=
- DPoP HTTP method/URL mismatch
- Malformed HTTP URL in DPoP= proof
- DPoP proof has already been used
- DPoP proof = is not active
- No access token hash in DPoP proof (when used wit= h an access token)
- DPoP proof access token hash mismatch (s= ame)

Would you recommend to a) provide detailed info (above) in error_description, b) provide generic "DPoP proof missing or invalid", c) omit=20 error_description?

Thanks,
Dmitry
<= /div>
O= n Tue, Aug 10, 2021 at 12:58 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org<= /a>> wrote:
<= div dir=3D"ltr">
Hi Dmitry,



On Thu, Aug 5= , 2021 at 8:50 AM Dmitry Telegin <dmitryt=3D40backbase.com@dmarc.ietf.org>= ; wrote:
Hello,

When a protected resource is= accessed using DPoP proof + DPoP-bound access token, either of those could= be invalid. Should we make distinction between these two cases? I.e. shoul= d the response always be a 401 Unauthorized with WWW-Authenticate: DPoP ...= error=3D"invalid_token"? or could we use error=3D"invalid_d= pop_proof", similar to token request? or maybe even 400 Bad Request?

Regards,
Dmitry

_______________________________________________
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.
--00000000000020427f05ccb4f3ae-- From nobody Fri Sep 24 06:18:43 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB663A2852 for ; Fri, 24 Sep 2021 06:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 J-agRWwxnQV2 for ; Fri, 24 Sep 2021 06:18:37 -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 C17D23A284E for ; Fri, 24 Sep 2021 06:18:36 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id i23so27536606wrb.2 for ; Fri, 24 Sep 2021 06:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pRp+QpD1Q2tukWX+6k7r5NRBOcjdye9+U4UhpvTBfUE=; b=EtN8jsJBvVuMoZNoG2VysEg/uYWGf53bfTV26lJ22006q1uJjfFmPrAq4SxrOEV63q zNd6mcMVib2noHcGc6NPvo1OkvphQrf6HZSbBBIS4fV1BCwolks9elKqudXot07Obgni hvm3ymuCwEVOqRskPSIkUJkEpWcAN3Ll/1c54dFUy67b+DU5aoYx8cxDxjIqedu9ajBk 2n3GU2pPe5jCifNrN8QzzdGRxk316ZxWy/Xu3sxNnhET2jxdh04iK7Mcr3udnZp9w+xM XHEoW4siHRzIZnYyvHUFdCyVozMZkSuyiJxrwnr+W3lxZVrFedG92PIIEp+Tcg4NgBxm rQOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pRp+QpD1Q2tukWX+6k7r5NRBOcjdye9+U4UhpvTBfUE=; b=IC/S1WI0qTqdFXm2lK0cL4M04L3JYCRcYfMFyRhKCadQPXd6a/30nGT5bZ4OJdkFv2 a7XBiAjoejm8LWDtvDGf59IoSoo0wekAlkWCBlawi75SEpYekHPmX2nhSxlcAytU16GO lul1M4Z59WNoRqMowmCviX9t5OZD+9prOucZ2zeUz2SzqK9NNztUm/pXAiAhZAi4t0Fp PZpBILc4jp4JsnTqbT5mK/K80haC45VudGm7fTmMl5iS6vaouUYF8dF6oOBIBMOBp+K4 uCMAZ+3UnEWacZLDjKBWXrTsK4zbSyDVZqe9qCjj1zMII4s95IvNp9fmtcFiZq6/tVFy h0jg== X-Gm-Message-State: AOAM532nhjlTcjFRtN2JAWLkHyZE/hSGxJiRFf6+ed75kh7ro0JWEZ3m K+Epd9R9pYPCEsPzJp862VnOq8Ipc6QRlFa5kLM= X-Google-Smtp-Source: ABdhPJyqpGRoudW6wHSfZPLrwS729AYwzKWmjRl2PfNGXxryxHMxavPW8Rs/lC92flzcEnAySkbHDDobrLpsOm75ihQ= X-Received: by 2002:a7b:c441:: with SMTP id l1mr2007239wmi.69.1632489515014; Fri, 24 Sep 2021 06:18:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Fri, 24 Sep 2021 09:18:24 -0400 Message-ID: To: Hannes Tschofenig Cc: oauth Content-Type: multipart/alternative; boundary="000000000000a45bbf05ccbd956a" Archived-At: Subject: Re: [OAUTH-WG] New Doodle Poll for OAuth Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Sep 2021 13:18:41 -0000 --000000000000a45bbf05ccbd956a Content-Type: text/plain; charset="UTF-8" All, The results of the poll indicates that our new time is *Wednesday, 12:00 EDT (=18:00 CEST)*. Thanks to all the people that participated in this poll. Regards, Rifaat & Hannes On Mon, Sep 20, 2021 at 2:04 PM Rifaat Shekh-Yusef wrote: > Just to add some color to this request. > > The goal is to find a new timeslot for our biweekly *OAuth WG Virtual > Office Hours *because we are having some issues with the existing > timeslot. > This new timeslot will also be used to host the *interim meetings *which > we are planning to start in the coming few weeks. > > Regards, > Rifaat & Hannes > > > On Mon, Sep 20, 2021 at 8:53 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > >> Hi all >> >> >> >> We are running a Doodle poll to find suitable times for our bi-weekly >> OAuth office hours. Here is the link: >> >> https://doodle.com/poll/2tf58dmmhvgi6rrt?utm_source=poll&utm_medium=link >> >> >> >> Ciao >> >> Hannes & Rifaat >> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --000000000000a45bbf05ccbd956a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

The results of the poll indicates = that our new time is=C2=A0Wednesday, 12:00 EDT (=3D18:00 CEST).
Thanks to all the people that participated in this poll.
Regards,
=C2=A0Rifaat & Hannes


On Mon, Sep 20, 2021 at 2:04 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Just to a= dd some color to this request.

The goal is to find a new= timeslot for our biweekly OAuth WG Virtual Office Hours because we = are having some issues with the existing timeslot.
This new times= lot will also be used to host the interim meetings which we are plan= ning to start in the coming few weeks.

Regards,
=C2=A0Rifaat & Hannes


On Mon, Sep 20, 2021= at 8:53 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all

=C2=A0

We are running a Doodle poll to find suitable times = for our bi-weekly OAuth office hours. Here is the link:

https://doodle.c= om/poll/2tf58dmmhvgi6rrt?utm_source=3Dpoll&utm_medium=3Dlink=

=C2=A0

Ciao

Hannes & Rifaat

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000a45bbf05ccbd956a-- From nobody Fri Sep 24 06:23:27 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278083A287D for ; Fri, 24 Sep 2021 06:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 VMAai4naZXoK for ; Fri, 24 Sep 2021 06:23:19 -0700 (PDT) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4365A3A285C for ; Fri, 24 Sep 2021 06:23:19 -0700 (PDT) Received: from rva2rmd101.webex.com (sjc02-wxpd-lb03-v140.webex.com [10.252.16.111]) by sjmda11.webex.com (Postfix) with ESMTP id 190EE300D854 for ; Fri, 24 Sep 2021 13:23:19 +0000 (GMT) Received: from rva2rmd101.webex.com (localhost [127.0.0.1]) by rva2rmd101.webex.com (Postfix) with ESMTP id AC85F1027709 for ; Fri, 24 Sep 2021 13:23:18 +0000 (GMT) Date: Fri, 24 Sep 2021 13:23:18 +0000 (GMT) From: Web Authorization Protocol Working Group Reply-To: oauth-chairs@ietf.org To: oauth@ietf.org Message-ID: <1139174857.7072421632489798705.JavaMail.nobody@rva2rmd101.webex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1414453_749045309.1632489798705" X-Priority: 3 Importance: normal X-WBX-INFO: X-WBX-SID=456680, X-WBX-CID=205989052526112044, X-WBX-TID=4s4480xfagmg86xfmdgcv969rluh7z99kfdmcng81jg0vf2cxih0beba, X-WBX-RID=f0e430caa6d24aefa6d475c6272aa302, X-WBX-SVC:Meeting Center, X-WBX-TT:Updated Meeting Invitation, Date:Fri Sep 24 13:23:18 GMT 2021 reminder-41.9.1-4524 Archived-At: Subject: [OAUTH-WG] Webex meeting changed: OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Sep 2021 13:23:24 -0000 ------=_Part_1414453_749045309.1632489798705 Content-Type: multipart/Alternative; boundary="----=_Part_1414454_1267051443.1632489798705" ------=_Part_1414454_1267051443.1632489798705 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CgpIaSwgb2F1dGhAaWV0Zi5vcmcsCgpXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5n IEdyb3VwIGNoYW5nZWQgdGhlIFdlYmV4IG1lZXRpbmcgaW5mb3JtYXRpb24uCgoKT0F1dGggV0cg VmlydHVhbCBPZmZpY2UgSG91cnMKT2NjdXJzIGV2ZXJ5IDIgd2VlayhzKSBvbiBXZWRuZXNkYXkg ZWZmZWN0aXZlIFdlZG5lc2RheSwgT2N0b2JlciA2LCAyMDIxIGZyb20gMTI6MDAgUE0gdG8gMTI6 MzAgUE0sIChVVEMtMDQ6MDApIEVhc3Rlcm4gVGltZSAoVVMgJiBDYW5hZGEpCjY6MDAgUE0gIHwg IChVVEMrMDI6MDApIEFtc3RlcmRhbSwgQmVybGluLCBCZXJuLCBSb21lLCBTdG9ja2hvbG0sIFZp ZW5uYSAgfCAgMzAgbWlucwpNZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDMgMTQ4IDU0 OCAKTWVldGluZyBwYXNzd29yZDogQldzQUY5clQKCgoKV2hlbiBpdCdzIHRpbWUsIGpvaW4gdGhl IG1lZXRpbmcuCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05OTI5NGY4 MWQwNTc5ZGVmNmFiYTYyYTU0YzFmYjAyYwoKQWRkIHRvIENhbGVuZGFyCmh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0xYzk4ZmY3ZGFhYTllNjAyOWVlMmQ4MGFiYmUzMTdj Ng0KDQoKCg0KVEFQIFRPIEpPSU4gRlJPTSBBIE1PQklMRSBERVZJQ0UgKEFUVEVOREVFUyBPTkxZ KQ0KKzEtNjUwLTQ3OS0zMjA4LCw2NDMxNDg1NDgjIyB0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCow MSo2NDMxNDg1NDglMjMlMjMqMDEqIENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkKDQoN CkpPSU4gQlkgUEhPTkUNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0Nh bmFkYSkKDQoNCgpKT0lOIEZST00gQSBWSURFTyBTWVNURU0gT1IgQVBQTElDQVRJT04KRGlhbCBz aXA6NjQzMTQ4NTQ4QGlldGYud2ViZXguY29tCllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42 OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci4KCgoKCgpDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPwpodHRwczovL2NvbGxhYm9yYXRpb25oZWxwLmNpc2NvLmNvbS9hcnRpY2xlL1dCWDAwMDAy OTA1NQoKCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2 aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNl c3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdh bCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25z ZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJl Y29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9p biB0aGUgc2Vzc2lvbi4K ------=_Part_1414454_1267051443.1632489798705 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KdGFibGUgewoJYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0 ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJYm9yZGVyLXNwYWNpbmc6IDA7fQoKdHIgewoJbGlu ZS1oZWlnaHQ6IDE4cHg7fQoKYSwgdGQgewoJZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTog QXJpYWw7CWNvbG9yOiAjMzMzOwl3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5v cm1hbDsJcGFkZGluZzogMDt9CgoudGl0bGUgewoJZm9udC1zaXplOiAyOHB4O30KCi5pbWFnZSB7 Cgl3aWR0aDogYXV0bzsJbWF4LXdpZHRoOiBhdXRvO30KCi5mb290ZXIgewoJd2lkdGg6IDYwNHB4 O30KCi5tYWluIHsKCn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgp IHsKCS50aXRsZSB7CgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX0KCS5pbWFnZSB7CgkJ d2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAwJSAhaW1wb3J0YW50Owl9Cgku Zm9vdGVyIHsKCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1w b3J0YW50Cgl9CgkubWFpbiB7CgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudAoJfQp9Cjwvc3R5bGU+Cgo8dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIg c3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAwJTsiIGFs aWduPSJsZWZ0Ij4KCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3Ry PgoJPHRyPgoJCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBweDsgbWFyZ2lu OiAwIj4KCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9yZGVyOiAwcHg7 IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6IDUwcHg7IiBh bGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPgoJCQkJPHRyPgoJCQkJCTx0ZCBhbGlnbj0iY2VudGVy IiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD4KCQkJCTwvdHI+CgkJCTwvdGFibGU+LS0+ CgoKCjx0YWJsZT4KICAgICAgICA8dHI+CiAgICAgICAgICAgIDx0ZD4KCQkJCTxwIHN0eWxlPSJm b250LXNpemU6IDE2cHg7Zm9udC1mYW1pbHk6IGFyaWFsO2NvbG9yOiMwMDAwMDA7Zm9udC13ZWln aHQ6IGJvbGQ7bGluZS1oZWlnaHQ6IDIycHg7Ij4KICAgICAgICAgICAgICAgICAgICBXZWIgQXV0 aG9yaXphdGlvbiBQcm90b2NvbCBXb3JraW5nIEdyb3VwIGNoYW5nZWQgdGhlIFdlYmV4IG1lZXRp bmcgaW5mb3JtYXRpb24uCiAgICAgICAgICAgICAgICA8L3A+CiAgICAgICAgICAgIDwvdGQ+CiAg ICAgICAgPC90cj4KICAgICAgICA8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+CgkJCTx0 ZCBzdHlsZT0iaGVpZ2h0OiAyMHB4OyI+Jm5ic3A7PC90ZD4KCQk8L3RyPgogICAgICAgIDx0cj4K ICAgICAgICAgICAgPHRkPgoJCQkJPHAgc3R5bGU9ImZvbnQtc2l6ZTogMTZweDtmb250LWZhbWls eTogYXJpYWw7Y29sb3I6IzAwMDAwMDtsaW5lLWhlaWdodDogMjJweDsiPgogICAgICAgICAgICAg ICAgICAgIFdoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuCiAgICAg ICAgICAgICAgICA8L3A+CiAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgPC90cj4KICAgICAgICA8 dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+CgkJCTx0ZCBzdHlsZT0iaGVpZ2h0OiAyMHB4 OyI+Jm5ic3A7PC90ZD4KCQk8L3RyPgo8L3RhYmxlPgoKCgoJCQkJCQk8dGFibGUgIHdpZHRoPSIx MDAlIj4KCQkJCQkJCTx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDE2cHg7Ij4KCQkJCQkJCQk8dGQg c3R5bGU9ImhlaWdodDogMTZweDsiPiZuYnNwOzwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRy ID4KCQkJCQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNjY2NjY2OyBmb250 LWZhbWlseTogYXJpYWw7IGxpbmUtaGVpZ2h0OiAyMnB4OyBtYXJnaW46IDA7Ij5PY2N1cnMgZXZl cnkgMiB3ZWVrKHMpIG9uIFdlZG5lc2RheSBlZmZlY3RpdmUgV2VkbmVzZGF5LCBPY3RvYmVyIDYs IDIwMjEgZnJvbSAxMjowMCBQTSB0byAxMjozMCBQTSwgKFVUQy0wNDowMCkgRWFzdGVybiBUaW1l IChVUyAmIENhbmFkYSkKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0cj4KCQkJ CQkJCQk8dGQgc3R5bGU9ImZvbnQtc2l6ZToxNnB4OyBjb2xvcjojNjY2NjY2OyBmb250LWZhbWls eTogYXJpYWw7IGxpbmUtaGVpZ2h0OiAyMnB4OyBtYXJnaW46IDA7Ij4KCQkJCQkJCQkJNjowMCBQ TSZuYnNwOyZuYnNwO3wmbmJzcDsmbmJzcDsoVVRDKzAyOjAwKSBBbXN0ZXJkYW0sIEJlcmxpbiwg QmVybiwgUm9tZSwgU3RvY2tob2xtLCBWaWVubmEmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MzAg bWlucwoJCQkJCQkJCTwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoKCTx0YWJsZSBz dHlsZT0icGFkZGluZy1ib3R0b206IDRweDtmb250LWZhbWlseTogQXJpYWw7Ij48dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+PC90YWJsZT4KCQk8dGFibGUgc3R5bGU9J3dpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRh bnQ7Jz48dHI+PHRkIHN0eWxlPSd3aWR0aDphdXRvIWltcG9ydGFudDsgJz48dGFibGUgYm9yZGVy PScwJyBjZWxscGFkZGluZz0nMCcgY2VsbHNwYWNpbmc9JzAnIHN0eWxlPSd3aWR0aDphdXRvO3dp ZHRoOmF1dG8haW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9yOiMwMDgyM0I7IGJvcmRlcjowcHgg c29saWQgIzAwODIzQjsgYm9yZGVyLXJhZGl1czoyMHB4OyBtaW4td2lkdGg6MTYwcHghaW1wb3J0 YW50Oyc+PHRib2R5Pjx0cj48dGQgYWxpZ249J2NlbnRlcicgc3R5bGU9J3BhZGRpbmc6MTBweCAz NnB4O2ZvbnQtZmFtaWx5OiBBcmlhbDsnPjxhIGhyZWY9J2h0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9qLnBocD9NVElEPW05OTI5NGY4MWQwNTc5ZGVmNmFiYTYyYTU0YzFmYjAyYycgc3R5bGU9 J2NvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsnPkpv aW4gbWVldGluZzwvYT48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxl Pjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OjI4cHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjI4 cHgiPiZuYnNwOzwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSJjb2xvcjojMDAwMDAwO2ZvbnQtZmFt aWx5OkFyaWFsO2ZvbnQtc2l6ZToxNHB4O2ZvbnQtd2VpZ2h0OmJvbGQ7bGluZS1oZWlnaHQ6MjRw eCI+PGI+TW9yZSB3YXlzIHRvIGpvaW46PC9iPjwvdGQ+PC90cj48dGFibGU+PHRyIHN0eWxlPSJs aW5lLWhlaWdodDoxMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+ PHRyPjx0ZCBzdHlsZT0iY29sb3I6IzAwMDAwMDtmb250LWZhbWlseTpBcmlhbDtmb250LXNpemU6 MTJweDtmb250LXdlaWdodDpib2xkO2xpbmUtaGVpZ2h0OjI0cHgiPjxiPkpvaW4gZnJvbSB0aGUg bWVldGluZyBsaW5rPC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHls ZT0iZm9udC1mYW1pbHk6QXJpYWw7Zm9udC1zaXplOjE0cHg7bGluZS1oZWlnaHQ6MjRweCI+PGEg aHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTk5Mjk0ZjgxZDA1 NzlkZWY2YWJhNjJhNTRjMWZiMDJjIiBzdHlsZT0iY29sb3I6IzAwNUU3RDt0ZXh0LWRlY29yYXRp b246bm9uZTtmb250LWZhbWlseTpBcmlhbDtmb250LXNpemU6MTRweDtsaW5lLWhlaWdodDoyNHB4 IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTk5Mjk0ZjgxZDA1NzlkZWY2YWJhNjJhNTRjMWZiMDJjPC9hPjwvdGQ+PC90cj48L3RhYmxlPgoK PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCgkJPHRhYmxlIHN0eWxlPSJ3aWR0aDphdXRv OyB3aWR0aDphdXRvIWltcG9ydGFudDsiPgoJCQk8dHI+CgkgICAgICAgICAgICA8dGQgc3R5bGU9 ImNvbG9yOiMwMDAwMDA7Zm9udC1mYW1pbHk6QXJpYWw7Zm9udC1zaXplOjEycHg7Zm9udC13ZWln aHQ6Ym9sZDtsaW5lLWhlaWdodDoyNHB4Ij4KCSAgICAgICAgICAgIAk8Yj5Kb2luIGJ5IG1lZXRp bmcgbnVtYmVyPC9iPgoJICAgICAgICAgICAgPC90ZD4KCSAgICAgICAgPC90cj4KCQk8L3RhYmxl PgoJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQ7Ij4KCQkJ PHRyPgoJCQkJPHRkIHN0eWxlPSJmb250LWZhbWlseTogYXJpYWw7IGNvbG9yOiAjMzMzMzMzOyBm b250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyMnB4OyI+CgkJCQkJTWVldGluZyBudW1iZXIg KGFjY2VzcyBjb2RlKTogNjQzIDE0OCA1NDgKCQkJCTwvdGQ+CgkJCTwvdHI+CgkJPC90YWJsZT4K CQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJPHRy ID4KCQkJCTx0ZCBzdHlsZT0iZm9udC1mYW1pbHk6IGFyaWFsOyBjb2xvcjogIzMzMzMzMzsgZm9u dC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjJweDsiPk1lZXRpbmcgcGFzc3dvcmQ6IEJXc0FG OXJUPC90ZD4KCQkJPC90cj4KCQk8L3RhYmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdo dDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxl PgoKCiA8Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCIgc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbDsiPjwvRk9OVD4KCiAgICAKCgk8dGFibGU+PHRyPjx0ZCBzdHlsZT0iY29sb3I6ICMwMDAw MDA7Zm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDEycHg7IGZvbnQtd2VpZ2h0OiBib2xk OyBsaW5lLWhlaWdodDogMjRweDsiPjxiPlRhcCB0byBqb2luIGZyb20gYSBtb2JpbGUgZGV2aWNl IChhdHRlbmRlZXMgb25seSk8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRk IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAy NHB4OyI+PGEgaHJlZj0ndGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqNjQzMTQ4NTQ4JTIzJTIz KjAxKicgc3R5bGU9J2NvbG9yOiMwMDVFN0Q7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1m YW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPisxLTY1MC00 NzktMzIwOCwsNjQzMTQ4NTQ4IyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8 L3RkPjwvdHI+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjRweCI+PHRkIHN0eWxlPSJoZWlnaHQ6 MjRweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0Ym9keT48dHI+PHRkIHN0eWxl PSJjb2xvcjogIzAwMDAwMDtmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC13ZWlnaHQ6IGJvbGQ7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiBieSBwaG9uZTwvYj48 L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNvbG9yOiAjMzMzMzMz O2ZvbnQtZmFtaWx5OiBBcmlhbDtmb250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Ij4x LTY1MC00NzktMzIwOCZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjogIzMzMzMzMzsiPkNhbGwtaW4g dG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L3NwYW4+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2lu OjBweCI+PHRkIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUt aGVpZ2h0OiAyNHB4OyI+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJsZT4KCTx0YWJsZT48dHIgc3R5 bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+PHRhYmxlPjx0cj48dGQgIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgZm9u dC1mYW1pbHk6IEFyaWFsO2ZvbnQtc2l6ZTogMTJweDsgZm9udC13ZWlnaHQ6IGJvbGQ7IGxpbmUt aGVpZ2h0OiAyNHB4OyI+PGI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9u PC9iPjwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMz MzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5lLWhlaWdodDog MjRweDsiPkRpYWwgPGEgaHJlZj0iIHNpcDo2NDMxNDg1NDhAaWV0Zi53ZWJleC5jb20iICAgc3R5 bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMDVFN0QiPjY0MzE0ODU0OEBpZXRmLndl YmV4LmNvbTwvYT48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQgc3R5bGU9ImNv bG9yOiAjMzMzMzMzOyBmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgbGluZS1o ZWlnaHQ6IDI0cHg7Ij5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlv dXIgbWVldGluZyBudW1iZXIuPC90ZD48L3RyPjwvdGFibGU+CiAgICAKCgk8dGFibGU+PHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90 ZD48L3RyPjwvdGFibGU+CgkKCgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0i bGVmdCIgY2xhc3M9Im1haW4iPgogICAgICAgICAgICAgICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDIw cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+CgkJCQk8dHI+CgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6 IDI0cHg7IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4 OyBsaW5lLWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cHM6Ly9o ZWxwLndlYmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwMDVFN0Q7IHRleHQtZGVjb3JhdGlvbjpub25l OyI+aHR0cHM6Ly9oZWxwLndlYmV4LmNvbTwvYT4KCQkJCQk8L3RkPgoJCQkJPC90cj4KICAgICAg ICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPgoJ CQk8L3RhYmxlPgoJCTwvdGQ+Cgk8L3RyPgo8L3RhYmxlPgo= ------=_Part_1414454_1267051443.1632489798705 Content-Type: text/calendar;method=REQUEST;charset=utf-8; Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNCkxBU1QtTU9ESUZJRUQ6MjAyMDEwMTFUMDE1 OTExWg0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25laW5mby1vdXRsb29rL0FtZXJpY2EvTmV3 X1lvcmsNClgtTElDLUxPQ0FUSU9OOkFtZXJpY2EvTmV3X1lvcmsNCkJFR0lOOkRBWUxJR0hUDQpU Wk5BTUU6RURUDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0MDANCkRUU1RBUlQ6 MTk3MDAzMDhUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTM7QllEQVk9MlNVDQpF TkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk5BTUU6RVNUDQpUWk9GRlNFVEZST006LTA0 MDANClRaT0ZGU0VUVE86LTA1MDANCkRUU1RBUlQ6MTk3MDExMDFUMDIwMDAwDQpSUlVMRTpGUkVR PVlFQVJMWTtCWU1PTlRIPTExO0JZREFZPTFTVQ0KRU5EOlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05F DQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMTA5MjRUMTMyMzE4Wg0KQVRURU5ERUU7Q049Im9h dXRoQGlldGYub3JnIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRo QGlldGYub3JnDQpPUkdBTklaRVI7Q049IldlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtp bmcgR3JvdXAiOk1BSUxUTzpvYXV0aC1jaGFpcnNAaWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1BbWVy aWNhL05ld19Zb3JrOjIwMjExMDA2VDEyMDAwMA0KRFRFTkQ7VFpJRD1BbWVyaWNhL05ld19Zb3Jr OjIwMjExMDA2VDEyMzAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTk5Mjk0ZjgxZDA1NzlkZWY2YWJhNjJhNTRjMWZiMDJjDQpUUkFOU1A6T1BBUVVF DQpTRVFVRU5DRToxNjMyNDg5Nzk4DQpVSUQ6MjA0NWQzNTctZmU3OC00OTBhLWI5MDQtNTYwZGM3 YWUzNjAyDQpERVNDUklQVElPTjpcblxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tOTkyOTRmODFkMDU3OWRlZjZhYmE2MmE1 NGMxZmIwMmNcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MyAxNDggNTQ4XG5cbk1l ZXRpbmcgcGFzc3dvcmQ6IEJXc0FGOXJUXG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9CSUxF IERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDY0MzE0ODU0OCMjIHRl bDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0MzE0ODU0OCUyMyUyMyowMSogQ2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZ U1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6NjQzMTQ4NTQ4QGlldGYud2ViZXguY29tXG5Z b3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1i ZXIuXG5cblxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3Jh dGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5P VElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRl ZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmlu ZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRp bmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91 ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpY LUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJs ZSB7XG4JYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJ Ym9yZGVyLXNwYWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0 ZCB7XG4JZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5c bi50aXRsZSB7XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJ bWF4LXdpZHRoOiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4g e1xuXG59QG1lZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRp dGxlIHtcbgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0 aDogYXV0byAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9v dGVyIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9y dGFudFxuCX1cbgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6 IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZG RkZGRiIgc3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAw JTsiIGFsaWduPSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwv dGQ+PC90cj5cbgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBw eDsgbWFyZ2luOiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJv cmRlcjogMHB4OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0 OiA1MHB4OyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBh bGlnbj0iY2VudGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxu CQkJPC90YWJsZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+ XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4g aXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3Rk PlxuCQkJCTwvdHI+XG4JCTwvdGFibGU+XG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsg Ij5cbgkJCQkJPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw IiBzdHlsZT0id2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9y OiMwMDgyM0I7IGJvcmRlcjowcHggc29saWQgIzAwODIzQjsgYm9yZGVyLXJhZGl1czoyNXB4OyBt aW4td2lkdGg6MTYwcHghaW1wb3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05OTI5NGY4MWQwNTc5ZGVmNmFiYTYyYTU0YzFm YjAyYyIgc3R5bGU9ImNvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRp b246bm9uZTsiPkpvaW4gbWVldGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJs ZT5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5cbgkJPHRhYmxlPlxuCQkJPHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj5cbgkJCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIzIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1vcmUgd2F5cyB0byBqb2luOjwvRk9OVD5cbgkJCQk8L3Rk PlxuICAgICAgICAJPC90cj5cbiAgICAgICAgICAgIDx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDogMTBweDsiPiZuYnNwOzwvdGQ+PC90cj5cbiAgICAgICAg CTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkpvaW4gZnJvbSB0aGUgbWVldGluZyBsaW5rPC9GT05UPlxuCQkJCTwvdGQ+XG4g ICAgICAgIAk8L3RyPlxuICAgICAgICAJPHRyPlxuCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0naHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTk5Mjk0ZjgxZDA1NzlkZWY2YWJhNjJhNTRjMWZiMDJj JyBzdHlsZT0nY29sb3I6IzAwNUU3RDsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWls eTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+aHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTk5Mjk0ZjgxZDA1NzlkZWY2YWJhNjJhNTRjMWZi MDJjPC9hPjwvRk9OVD5cbgkJCQk8L3RkPlxuICAgICAgICAJPC90cj5cbiAgICAgICAgCTx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMyIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IG1lZXRpbmcgbnVtYmVyPC9GT05UPlxuCQkJ CTwvdGQ+XG4gICAgICAgIAk8L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZD5cbgkJCQkJPEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNz IGNvZGUpOiA2NDMgMTQ4IDU0ODwvRk9OVD5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJs ZT5cbgkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5CV3NBRjlyVDwvRk9OVD48L3RkPjwvdHI+PC90 YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsOyI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFS SUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlRhcCB0byBq b2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L0ZPTlQ+ICZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSd0 ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDMxNDg1NDglMjMlMjMqMDEqJyBzdHlsZT0nY29s b3I6IzAwNUU3RDsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9u dC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUwLTQ3OS0zMjA4LCw2NDMxNDg1 NDgjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJS PjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MS02NTAtNDc5LTMyMDggQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48 QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZB Q0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpv aW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJz aXA6NjQzMTQ4NTQ4QGlldGYud2ViZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwNUU3 RCIgRkFDRT0iYXJpYWwiPjY0MzE0ODU0OEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7 IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZP TlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZuYnNwOyA8QlI+XG5cblxuXG4JPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj48L3RhYmxlPlxuCVxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249 ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDog MjBweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVp Z2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTog MTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHBz Oi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDA1RTdEOyB0ZXh0LWRlY29yYXRpb246 bm9uZTsiPmh0dHBzOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5c biAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6 T0F1dGggV0cgVmlydHVhbCBPZmZpY2UgSG91cnMNClBSSU9SSVRZOjUNCkNMQVNTOlBVQkxJQw0K UlJVTEU6RlJFUT1XRUVLTFk7V0tTVD1TVTtJTlRFUlZBTD0yO0JZREFZPVdFDQpCRUdJTjpWQUxB Uk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0K RU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K ------=_Part_1414454_1267051443.1632489798705-- ------=_Part_1414453_749045309.1632489798705 Content-Type: application/octet-stream; name="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Webex_Meeting.ics" QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNCkxBU1QtTU9ESUZJRUQ6MjAyMDEwMTFUMDE1 OTExWg0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25laW5mby1vdXRsb29rL0FtZXJpY2EvTmV3 X1lvcmsNClgtTElDLUxPQ0FUSU9OOkFtZXJpY2EvTmV3X1lvcmsNCkJFR0lOOkRBWUxJR0hUDQpU Wk5BTUU6RURUDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0MDANCkRUU1RBUlQ6 MTk3MDAzMDhUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTM7QllEQVk9MlNVDQpF TkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk5BTUU6RVNUDQpUWk9GRlNFVEZST006LTA0 MDANClRaT0ZGU0VUVE86LTA1MDANCkRUU1RBUlQ6MTk3MDExMDFUMDIwMDAwDQpSUlVMRTpGUkVR PVlFQVJMWTtCWU1PTlRIPTExO0JZREFZPTFTVQ0KRU5EOlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05F DQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMTA5MjRUMTMyMzE4Wg0KQVRURU5ERUU7Q049Im9h dXRoQGlldGYub3JnIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOm9hdXRo QGlldGYub3JnDQpPUkdBTklaRVI7Q049IldlYiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtp bmcgR3JvdXAiOk1BSUxUTzpvYXV0aC1jaGFpcnNAaWV0Zi5vcmcNCkRUU1RBUlQ7VFpJRD1BbWVy aWNhL05ld19Zb3JrOjIwMjExMDA2VDEyMDAwMA0KRFRFTkQ7VFpJRD1BbWVyaWNhL05ld19Zb3Jr OjIwMjExMDA2VDEyMzAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2ou cGhwP01USUQ9bTk5Mjk0ZjgxZDA1NzlkZWY2YWJhNjJhNTRjMWZiMDJjDQpUUkFOU1A6T1BBUVVF DQpTRVFVRU5DRToxNjMyNDg5Nzk4DQpVSUQ6MjA0NWQzNTctZmU3OC00OTBhLWI5MDQtNTYwZGM3 YWUzNjAyDQpERVNDUklQVElPTjpcblxuXG5cblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tOTkyOTRmODFkMDU3OWRlZjZhYmE2MmE1 NGMxZmIwMmNcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDY0MyAxNDggNTQ4XG5cbk1l ZXRpbmcgcGFzc3dvcmQ6IEJXc0FGOXJUXG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEgTU9CSUxF IERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDY0MzE0ODU0OCMjIHRl bDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjY0MzE0ODU0OCUyMyUyMyowMSogQ2FsbC1pbiB0b2xs IG51bWJlciAoVVMvQ2FuYWRhKVxuXG5cbkpPSU4gQlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuXG5cbkpPSU4gRlJPTSBBIFZJREVPIFNZ U1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6NjQzMTQ4NTQ4QGlldGYud2ViZXguY29tXG5Z b3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1i ZXIuXG5cblxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz9cbmh0dHBzOi8vY29sbGFib3Jh dGlvbmhlbHAuY2lzY28uY29tL2FydGljbGUvV0JYMDAwMDI5MDU1XG5cblxuSU1QT1JUQU5UIE5P VElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRl ZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmlu ZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRp bmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91 ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuDQpY LUFMVC1ERVNDO0ZNVFRZUEU9dGV4dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG50YWJs ZSB7XG4JYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgd2lkdGggPTEwMCU7CWJvcmRlcjogMDsJ Ym9yZGVyLXNwYWNpbmc6IDA7fVxuXG50ciB7XG4JbGluZS1oZWlnaHQ6IDE4cHg7fVxuXG5hLCB0 ZCB7XG4JZm9udC1zaXplOiAxNHB4Owlmb250LWZhbWlseTogQXJpYWw7CWNvbG9yOiAjMzMzOwl3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7CXdvcmQtYnJlYWs6IG5vcm1hbDsJcGFkZGluZzogMDt9XG5c bi50aXRsZSB7XG4JZm9udC1zaXplOiAyOHB4O31cblxuLmltYWdlIHtcbgl3aWR0aDogYXV0bzsJ bWF4LXdpZHRoOiBhdXRvO31cblxuLmZvb3RlciB7XG4Jd2lkdGg6IDYwNHB4O31cblxuLm1haW4g e1xuXG59QG1lZGlhIHNjcmVlbiBhbmQgKG1heC1kZXZpY2Utd2lkdGg6IDgwMHB4KSB7XG4JLnRp dGxlIHtcbgkJZm9udC1zaXplOiAyMnB4ICFpbXBvcnRhbnQ7CX1cbgkuaW1hZ2Uge1xuCQl3aWR0 aDogYXV0byAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CX1cbgkuZm9v dGVyIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDogNjA0cHggIWltcG9y dGFudFxuCX1cbgkubWFpbiB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6 IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG59XG48L3N0eWxlPlxuXG48dGFibGUgYmdjb2xvcj0iI0ZG RkZGRiIgc3R5bGU9InBhZGRpbmc6IDA7IG1hcmdpbjogMDsgYm9yZGVyOiAwOyB3aWR0aDogMTAw JTsiIGFsaWduPSJsZWZ0Ij5cbgk8dHIgc3R5bGU9ImhlaWdodDogMjhweCI+PHRkPiZuYnNwOzwv dGQ+PC90cj5cbgk8dHI+XG4JCTx0ZCBhbGlnbj0ibGVmdCIgc3R5bGU9InBhZGRpbmc6IDAgMjBw eDsgbWFyZ2luOiAwIj5cbgkJCTwhLS08dGFibGUgYmdjb2xvcj0iI0ZGRkZGRiIgc3R5bGU9ImJv cmRlcjogMHB4OyB3aWR0aDogMTAwJTsgcGFkZGluZy1sZWZ0OiA1MHB4OyBwYWRkaW5nLXJpZ2h0 OiA1MHB4OyIgYWxpZ249ImxlZnQiIGNsYXNzPSJtYWluIj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBh bGlnbj0iY2VudGVyIiB2YWxpZ249InRvcCIgPiZuYnNwOwkJCQkJPC90ZD5cbgkJCQk8L3RyPlxu CQkJPC90YWJsZT4tLT5cblxuXG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJCQk8dGQ+ XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPldoZW4g aXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05UPlxuCQkJCQk8L3Rk PlxuCQkJCTwvdHI+XG4JCTwvdGFibGU+XG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsg Ij5cbgkJCQkJPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIw IiBzdHlsZT0id2lkdGg6YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9y OiMwMDgyM0I7IGJvcmRlcjowcHggc29saWQgIzAwODIzQjsgYm9yZGVyLXJhZGl1czoyNXB4OyBt aW4td2lkdGg6MTYwcHghaW1wb3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0 Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05OTI5NGY4MWQwNTc5ZGVmNmFiYTYyYTU0YzFm YjAyYyIgc3R5bGU9ImNvbG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRp b246bm9uZTsiPkpvaW4gbWVldGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJs ZT5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5cbgkJPHRhYmxlPlxuCQkJPHRyIHN0 eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwv dGQ+PC90cj5cbgkJCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIzIiBDT0xPUj0i IzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1vcmUgd2F5cyB0byBqb2luOjwvRk9OVD5cbgkJCQk8L3Rk PlxuICAgICAgICAJPC90cj5cbiAgICAgICAgICAgIDx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDogMTBweDsiPiZuYnNwOzwvdGQ+PC90cj5cbiAgICAgICAg CTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPkpvaW4gZnJvbSB0aGUgbWVldGluZyBsaW5rPC9GT05UPlxuCQkJCTwvdGQ+XG4g ICAgICAgIAk8L3RyPlxuICAgICAgICAJPHRyPlxuCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PGEgaHJlZj0naHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTk5Mjk0ZjgxZDA1NzlkZWY2YWJhNjJhNTRjMWZiMDJj JyBzdHlsZT0nY29sb3I6IzAwNUU3RDsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWls eTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+aHR0cHM6Ly9pZXRm LndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTk5Mjk0ZjgxZDA1NzlkZWY2YWJhNjJhNTRjMWZi MDJjPC9hPjwvRk9OVD5cbgkJCQk8L3RkPlxuICAgICAgICAJPC90cj5cbiAgICAgICAgCTx0ciBz dHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8 L3RkPjwvdHI+XG4JCQk8dHI+XG4JCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMyIgQ09MT1I9 IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IG1lZXRpbmcgbnVtYmVyPC9GT05UPlxuCQkJ CTwvdGQ+XG4gICAgICAgIAk8L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZD5cbgkJCQkJPEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNz IGNvZGUpOiA2NDMgMTQ4IDU0ODwvRk9OVD5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJs ZT5cbgkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9 ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAg Q09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5CV3NBRjlyVDwvRk9OVD48L3RkPjwvdHI+PC90 YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsOyI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFS SUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlRhcCB0byBq b2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L0ZPTlQ+ICZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSd0 ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSo2NDMxNDg1NDglMjMlMjMqMDEqJyBzdHlsZT0nY29s b3I6IzAwNUU3RDsgIHRleHQtZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9u dC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAyNHB4Oyc+KzEtNjUwLTQ3OS0zMjA4LCw2NDMxNDg1 NDgjIzwvYT4gQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJS PjxCUj48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2 NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiAmbmJzcDsgPEJSPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+MS02NTAtNDc5LTMyMDggQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4gJm5ic3A7IDxCUj48Rk9OVCBTSVpF PSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjwvRk9OVD4mbmJzcDsgPEJSPjxCUj48 QlI+XG5cbjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJo ZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+XG5cbjxGT05UIFNJWkU9IjQiIEZB Q0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpv aW4gZnJvbSBhIHZpZGVvIHN5c3RlbSBvciBhcHBsaWNhdGlvbjwvRk9OVD48QlI+PEZPTlQgU0la RT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5EaWFsPC9GT05UPiA8YSBocmVmPSJz aXA6NjQzMTQ4NTQ4QGlldGYud2ViZXguY29tIj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzAwNUU3 RCIgRkFDRT0iYXJpYWwiPjY0MzE0ODU0OEBpZXRmLndlYmV4LmNvbTwvRk9OVD48L2E+Jm5ic3A7 IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPllvdSBjYW4g YWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci48L0ZP TlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZuYnNwOyA8QlI+XG5cblxuXG4JPHRhYmxlPjx0ciBzdHls ZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+ PC90cj48L3RhYmxlPlxuCVxuXG4JCQk8dGFibGUgc3R5bGU9IndpZHRoOiAxMDAlOyIgYWxpZ249 ImxlZnQiIGNsYXNzPSJtYWluIj5cbiAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDog MjBweCI+PHRkPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4JCQkJCTx0ZCBzdHlsZT0iaGVp Z2h0OiAyNHB4OyBjb2xvcjogIzAwMDAwMDsgZm9udC1mYW1pbHk6QXJpYWw7IGZvbnQtc2l6ZTog MTRweDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij5OZWVkIGhlbHA/IEdvIHRvIDxhIGhyZWY9Imh0dHBz Oi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDA1RTdEOyB0ZXh0LWRlY29yYXRpb246 bm9uZTsiPmh0dHBzOi8vaGVscC53ZWJleC5jb208L2E+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5c biAgICAgICAgICAgICAgICA8dHIgc3R5bGU9ImhlaWdodDogNDRweCI+PHRkPiZuYnNwOzwvdGQ+ PC90cj5cbgkJCTwvdGFibGU+XG4JCTwvdGQ+XG4JPC90cj5cbjwvdGFibGU+XG4NClNVTU1BUlk6 T0F1dGggV0cgVmlydHVhbCBPZmZpY2UgSG91cnMNClBSSU9SSVRZOjUNCkNMQVNTOlBVQkxJQw0K UlJVTEU6RlJFUT1XRUVLTFk7V0tTVD1TVTtJTlRFUlZBTD0yO0JZREFZPVdFDQpCRUdJTjpWQUxB Uk0NClRSSUdHRVI6LVBUNU0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSZW1pbmRlcg0K RU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K ------=_Part_1414453_749045309.1632489798705-- From nobody Fri Sep 24 06:26:56 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17B53A28AB for ; Fri, 24 Sep 2021 06:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 uUZb1eRAE0aE for ; Fri, 24 Sep 2021 06:26:51 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CA23A28A6 for ; Fri, 24 Sep 2021 06:26:50 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id g16so27541284wrb.3 for ; Fri, 24 Sep 2021 06:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=VuaULdXufJVJpvPN1ciujpo8K5RyJ0bAuQ82Di0IOD8=; b=GYxbrvpqrdB4lwdS4vKms7DVqIEntUPPTINcqWnjSMgR0LDqgUc5xhsP2p4BI4sxdB uuoHlUxVY53Eba034A0Qz8iYLhQvAaS6N/urPVa7g/m2N1FLYWnzJKbAS7APdBxpH2yT T+G/+DrD5IbyMMQBeTpW92NJ5uZ6lo/gBKkuHomh3oQde948Q/9o1A1UIOwF8uNfQcph edLXVr5K1lcSL5lj4r95sk6TGvvlA6FD0AwL+Kh++rdIiMxpmgXKN9MDAIBFlj+VETTA 9oPLTBP5bNtiFJdJG9zlw99OiEV1/6Mc+YWavuV2if7uqpJYMYZsIygwR315FJ3DZy+G 4khQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=VuaULdXufJVJpvPN1ciujpo8K5RyJ0bAuQ82Di0IOD8=; b=Vc1u3mwObM8GwSQw10a6ZIlawFVp+SLEvjBmzMbXLGSNW43jTsjBry6WbJIoqZRQj/ lvarf+p8g6X3PXdHOzFcjl0sGbhT875/D6ci1ThW5+POB7QiLUBTycI0eImU0pDkQoGz UWAvVWIc6rK4cwx1qQ5O3MmpDjl6u/6eFskheKk7afrVTBYSoGZybPijRqbGEnnxml6t MHzncXLkpwdI6nhmzNewfoSqM/7iv6/3P4mZCIFhwdfPNOG92dcLULWlvcPmlxvMs0fr dGpkZqS2XrrnjoK9CA6OjQ24cLptNtPlAdjOdM1kzjjeLa2GX2bh6oADZYjoN6dr4XJ7 cryw== X-Gm-Message-State: AOAM533X13GSRFqtEmeg571oDV9mPYD33lOXWLl36eW0J6MjB7yEDI+J xQuqy8Uye3TOHRuC3bBbJkyx9To5AvqJSh5rdsIkeci+ X-Google-Smtp-Source: ABdhPJxGEBk2UbvpodmaTRdd6ZZXZoLJ4TjSdA4DCabrDyLcjIs2j8+0NVOyvqlQekSAwzh9qNm1oVWnV29ew9M4iL8= X-Received: by 2002:a7b:c441:: with SMTP id l1mr2049244wmi.69.1632490006990; Fri, 24 Sep 2021 06:26:46 -0700 (PDT) MIME-Version: 1.0 References: <1139174857.7072421632489798705.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <1139174857.7072421632489798705.JavaMail.nobody@rva2rmd101.webex.com> From: Rifaat Shekh-Yusef Date: Fri, 24 Sep 2021 09:26:36 -0400 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000f752ba05ccbdb2d2" Archived-At: Subject: Re: [OAUTH-WG] Webex meeting changed: OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-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, 24 Sep 2021 13:26:56 -0000 --000000000000f752ba05ccbdb2d2 Content-Type: text/plain; charset="UTF-8" All, This is the invitation for our new timeslot starting *October 6th*. Regards, Rifaat & Hannes On Fri, Sep 24, 2021 at 9:23 AM Web Authorization Protocol Working Group wrote: > > > Web Authorization Protocol Working Group changed the Webex meeting > information. > > > When it's time, join the Webex meeting here. > > > Occurs every 2 week(s) on Wednesday effective Wednesday, October 6, 2021 > from 12:00 PM to 12:30 PM, (UTC-04:00) Eastern Time (US & Canada) > 6:00 PM | (UTC+02:00) Amsterdam, Berlin, Bern, Rome, Stockholm, > Vienna | 30 mins > > Join meeting > > > *More ways to join:* > > *Join from the meeting link* > https://ietf.webex.com/ietf/j.php?MTID=m99294f81d0579def6aba62a54c1fb02c > > *Join by meeting number* > Meeting number (access code): 643 148 548 > Meeting password: BWsAF9rT > > *Tap to join from a mobile device (attendees only)* > +1-650-479-3208,,643148548## <%2B1-650-479-3208,,*01*643148548%23%23*01*> > Call-in toll number (US/Canada) > > *Join by phone* > 1-650-479-3208 Call-in toll number (US/Canada) > > *Join from a video system or application* > Dial 643148548@ietf.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > > > Need help? Go to https://help.webex.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000f752ba05ccbdb2d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

This is the=C2=A0invitation=C2=A0f= or our new timeslot starting October 6th.

R= egards,
=C2=A0Rifaat & Hannes


<= div class=3D"gmail_quote">
On Fri, Sep= 24, 2021 at 9:23 AM Web Authorization Protocol Working Group <messenger= =3D40webex.com@dmarc.ietf.org= > wrote:
=C2=A0
=09

Web Authorization Protocol Working Group changed the We= bex meeting information.

=C2=A0

When it's time, join the Webex meeting here.

=C2=A0
=C2=A0
Occurs every 2 week(s) on Wednesday effectiv= e Wednesday, October 6, 2021 from 12:00 PM to 12:30 PM, (UTC-04:00) Eastern= Time (US & Canada)
6:00 PM=C2=A0=C2=A0|=C2=A0=C2=A0(UTC+02:00) Amsterdam, Berlin, Ber= n, Rome, Stockholm, Vienna=C2=A0=C2=A0|=C2=A0=C2=A030 mins
=C2=A0
Join meeting
=C2=A0
<= b>More ways to join:
<= td style=3D"font-family:Arial;font-size:14px;line-height:24px">https://ietf.webex.com/ietf/j.p= hp?MTID=3Dm99294f81d0579def6aba62a54c1fb02c
=C2=A0
Join from the meeting link
=C2= =A0
Join by meeting number
Meeting number (access code): 643 148 548
Meeting password: BWsAF9rT
=C2= =A0
=20 <= tr style=3D"line-height:24px">
Tap to join from a mobile devi= ce (attendees only)
= +1-650-479-3208,,643148548## Call-in toll number (US/Canada)
=C2=A0
Join by phone<= /td>
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
=C2= =A0
=20
Jo= in from a video system or application
Dial 643148= 548@ietf.webex.com
You can a= lso dial 173.243.2.68 and enter your meeting number.
=C2= =A0
=09
=C2=A0
Need help? Go to https:= //help.webex.com
=C2=A0
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000f752ba05ccbdb2d2-- From nobody Sat Sep 25 04:07:32 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BA33A0839 for ; Sat, 25 Sep 2021 04:07: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20210112.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 oyEFhpMuHLoD for ; Sat, 25 Sep 2021 04:07:27 -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 AA3A53A0837 for ; Sat, 25 Sep 2021 04:07:27 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id e82so15936213iof.5 for ; Sat, 25 Sep 2021 04:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20210112.gappssmtp.com; s=20210112; h=from:mime-version:date:message-id:subject:to; bh=8SctCPT55fxTCRvk6V3FyISkJdnpqosIcwl15abiwcM=; b=egRi8kSKO1brjPXEa9TvDX6guJmpkTgDcdMbtF3ybSwPV85BTZTzNlg4Gn6fP/2/t2 x15Bah7I9eGU1D/dNkUiDbOhpTw9k6mIP3tS3YR+xfT3lPhKgZael3+ylbjCjo3V/PTW xBUR4WdM85oTGK/Km4ST5Zk1BpVz2655CPH9EBHdXI7T1KNbJMEbFz44yv7QRtZIb/uA dIex8Pzu+L9zPRxKy2KCk7L8FSg4DfhcPIkpBZqsBJBIsHHR2fkW2T0TGIMKCywHPkRl sPVClVdrXHeR3JlGVdpXEi/QYIP36ipBLqpx0wAmiNE1d6x/OdXMdubDfx1RrghYdRT7 RHaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=8SctCPT55fxTCRvk6V3FyISkJdnpqosIcwl15abiwcM=; b=CPI9ch2ndq0t7VBBHorFpOQl1AiRW9j/+qHdmO7qzhxVXcoxaBUz1V4YHRACdleFOG XRiSA8aaUxLLTYDbvSk6NKMMIzN0xn46M/+soJE91ZJeHMhEtf4hts0KGZUQ8/5T2s17 oqWEXuRrcHOwGYyjPa/IhFfcuRDxj98uYsvzI7oFbGecMJE45W+EzuFwnnIcvU32xY3u 7kTtVb7bUX/krJqXMC67LBFoWTjjZl/8fg1dt6UDRupI38+3y433wGYgm9QTWR2JVRYl feBm7LC8hv7KkLgqhKye0x+bp9oHBJkrG9YoByClyZJ+5iyUcDdTt7MhsqlXvZDwyeBr mfdw== X-Gm-Message-State: AOAM533WrHxN1A3IsOgqzqbIxv0bU/pceTvJ/phcpX4ZEEJQi+8Iaz4V H+u0AdWAQaHEVRSXTbH/qFYTgUyIlxHv6WK9bgBi2RmNCg== X-Google-Smtp-Source: ABdhPJyyJcOLA6LHWWxPyhnRK61+gO1OfCsLOuIIlurM2hRwSrQPPIZlAykKY+oFfOVtmRqIjrb0t/gZItcn9eLt8o8= X-Received: by 2002:a05:6602:2c0f:: with SMTP id w15mr13276835iov.106.1632568046329; Sat, 25 Sep 2021 04:07:26 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 25 Sep 2021 04:07:25 -0700 From: Dominick Baier MIME-Version: 1.0 Date: Sat, 25 Sep 2021 04:07:25 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000793c1e05cccfde11" Archived-At: Subject: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2021 11:07:30 -0000 --000000000000793c1e05cccfde11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In 6.1 it says "Additionally, the SameSite cookie attribute can be used to prevent CSRF attacks, or alternatively, the application and API could be written to use anti-CSRF tokens.=E2=80=9D =E2=80=9CPrevent=E2=80=9D is a bit strong. SameSite only restricts cookies sent across site boundaries Iit does not prevent CSRF attacks from within a site boundary. Scenarios could be a compromised sub-domain, like sub-domain takeover or just some vulnerable application co-located on the same site. thanks =E2=80=94=E2=80=94=E2=80=94 Dominick Baier --000000000000793c1e05cccfde11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
In 6= .1 it says
<= br>
"Additionally, the SameSite cookie attribute= can be used to
=C2=A0 =C2=A0 prevent CSRF attacks, or alternati= vely, the application and API could
=C2=A0 =C2=A0 be written to= use anti-CSRF tokens.=E2=80=9D

=E2=80=9CPrevent=E2=80=9D is a bit strong.

SameSite only re= stricts cookies sent across site boundaries Iit does not prevent CSRF attac= ks from within a site boundary. Scenarios could be a compromised sub-domain= , like sub-domain takeover or just some vulnerable application co-located o= n the same site.

thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier
--000000000000793c1e05cccfde11-- From nobody Sat Sep 25 10:20:04 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1F73A1B26 for ; Sat, 25 Sep 2021 10:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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=manicode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6t9fYosBshu for ; Sat, 25 Sep 2021 10:19:57 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31E03A1B25 for ; Sat, 25 Sep 2021 10:19:57 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id m26so11737198pff.3 for ; Sat, 25 Sep 2021 10:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=5Ue+dftUlEMlOnwQdK9HaUxAmwfViIv2w1acWTZTyaA=; b=oS5OIv3P8MR0LyqbqCNerEC3GfHSakhbpSnanUaILnQL5eUZVks+qgw7DBtrpJ1uxI XBkXjSbkzdTlNaC9tNsnxQB/j0RwvsqUZEP/8ebghL/YjKfTwCQ2bXzDNS4buiLupcMF Kk3X+JrzBtUoL5XoDPohQKhtzq1+gU+tzuC74lmV5c5HX0VuuJwpek3PvkuoijD9ihTn vinBUj4SkELAwvAAFv9uS0lZkxM8IZu+PZKnW9aPa5H4q3jdh/0YYmwtdXQEMG+k/pyw UYBEg6cWNKkJeW4Zpmcv1P66a0jjh/wtR0zsl8Sxyw/8nXcitB4b+51k7KUMPHH58WwO bxow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=5Ue+dftUlEMlOnwQdK9HaUxAmwfViIv2w1acWTZTyaA=; b=mDHvEXrJX/zLEKNswJ3SnUhcXv49leYo1owviwIK/a1f35hFsS65y5Y6JDKHqAcLb0 GFERWrqNBcL610X418TJsZfMHaBx8UOzeVcUGMeQ/93gsAQbdtn5FUim6fvEUUUd7ZUQ YlsAhC0Uf1mUCUQY6EmiSwCbakyRIyBGI5JQqhCl3C3RD+vJ0/8xKPqHCTyOCyxeeJHg +l9xIdSibbTPkNMbJgnYi4m7ffxDl/Ks0CT4bjshHgg5Mx5lzTIhq5KJ5vA+2XXYvEbp HGzpAombQ/uFtTCMAZwoFegNLtRsmpX5DGhbBSZu6FI/2zgsXLBp4eLsPJ9PEK/O2Q6T MrTg== X-Gm-Message-State: AOAM531aKPYfHFDiwjKNEeUA+TJw+iyNhOeboC3bOqImUtNoA+PbUMoo Q9GvDMoJ5mBIAzfo2dAQOe3d/9ANcfIQJg== X-Google-Smtp-Source: ABdhPJxf+Ab0mCOrTE9L8ZImTjf83DIHW+cDAN15vY9CzIuVudtz9aSnYIVdI22O/8RoYo8EZ/UEjQ== X-Received: by 2002:a63:4e65:: with SMTP id o37mr9163094pgl.202.1632590396680; Sat, 25 Sep 2021 10:19:56 -0700 (PDT) Received: from smtpclient.apple (204-210-127-015.res.spectrum.com. [204.210.127.15]) by smtp.gmail.com with ESMTPSA id y204sm12047783pfc.100.2021.09.25.10.19.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Sep 2021 10:19:55 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-FDBDA01B-A698-4691-9D83-0FA6E64C0A85 Content-Transfer-Encoding: 7bit From: Jim Manico Mime-Version: 1.0 (1.0) Date: Sat, 25 Sep 2021 07:19:54 -1000 Message-Id: <2EA892D6-D2F5-46AA-9B03-63F7AC4C5A69@manicode.com> References: Cc: oauth In-Reply-To: To: Dominick Baier X-Mailer: iPhone Mail (19A346) Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2021 17:20:03 -0000 --Apple-Mail-FDBDA01B-A698-4691-9D83-0FA6E64C0A85 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If someone has taken over a subdomain in the ways described, that is not cro= ss site request forgery since the attack is occurring from within your site.= It=E2=80=99s more likely XSS that allows for cookie clobbering or similar, o= r just malicious code injected by the malicious controller of your subdomain= . This is not strictly CSRF nor are these problems protected from any other s= tandard form of CSRF defense. CSRF is Cross Site attack where the attack is hosted on a different domain.=20= -- Jim Manico > On Sep 25, 2021, at 1:07 AM, Dominick Baier wr= ote: >=20 > =EF=BB=BF > In 6.1 it says >=20 > "Additionally, the SameSite cookie attribute can be used to=09 > prevent CSRF attacks, or alternatively, the application and API c= ould=09 > be written to use anti-CSRF tokens.=E2=80=9D >=20 > =E2=80=9CPrevent=E2=80=9D is a bit strong. >=20 > SameSite only restricts cookies sent across site boundaries Iit does not p= revent CSRF attacks from within a site boundary. Scenarios could be a compro= mised sub-domain, like sub-domain takeover or just some vulnerable applicati= on co-located on the same site. >=20 > thanks > =E2=80=94=E2=80=94=E2=80=94 > Dominick Baier > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-FDBDA01B-A698-4691-9D83-0FA6E64C0A85 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable If someone has taken over a subdomain in th= e ways described, that is not cross site request forgery since the attack is= occurring from within your site. It=E2=80=99s more likely XSS that allows f= or cookie clobbering or similar, or just malicious code injected by the mali= cious controller of your subdomain. This is not strictly CSRF nor are these p= roblems protected from any other standard form of CSRF defense.
CSRF is Cross Site attack where the attack is hosted on a differ= ent domain. 

--
Jim Manico
=

On Sep 25, 2021, at 1:0= 7 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:

=EF=BB=BF
In 6.1 it says

"Additionally, t= he SameSite cookie attribute can be used to
&nbs= p; &nb= sp; prevent CSRF attacks, or alternatively, the application and API could
    be written to use anti-CSRF tokens.=E2=80=9D

=E2=80=9CPrevent= =E2=80=9D is a bit strong.

SameSite only restricts cookies sent across site boundarie= s Iit does not prevent CSRF attacks from within a site boundary. Scenarios c= ould be a compromised sub-domain, like sub-domain takeover or just some vuln= erable application co-located on the same site.

thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Ba= ier
_______________________________________________
OAuth m= ailing list
OAuth@ietf.org
https://www.ietf.= org/mailman/listinfo/oauth
<= /html>= --Apple-Mail-FDBDA01B-A698-4691-9D83-0FA6E64C0A85-- From nobody Sat Sep 25 11:11:11 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739073A1D65 for ; Sat, 25 Sep 2021 11:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 IZCSsyUMDNSA for ; Sat, 25 Sep 2021 11:11:03 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FB93A1D62 for ; Sat, 25 Sep 2021 11:11:02 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id w17so37488760wrv.10 for ; Sat, 25 Sep 2021 11:11:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=zIXGhMRbLkdQfmH6HnLevzdeo5jtY1K1Xck/RuWj+xc=; b=W0dWZHzsRQnF19Inzl1c3EMAh8o/Oe0EBxkxmFXBfvVQe1pFIhcKXLPsR12/d1SF2L ZHsX7Y5Ac+Yr4Y2vvG3LDyJ12aW6czM7twc9QwBO3JVyDEfUI22eBjTbXDASHisoPINy gLqSNMxCJ4eU0IY0+HIIAgJMcDwXWpIxnP2ZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=zIXGhMRbLkdQfmH6HnLevzdeo5jtY1K1Xck/RuWj+xc=; b=pINk0gFKnP7gGD51dHtF2tquxzELwzpP2xsv7PJFJTSjjeHj7pfVT42k6t3gbkRc1P XadmJFRwLbcuRqfbxx+r2V3UMLswXnIrOD3Nn2JAIvQ3PqBzAHTJ/d60c4JOtvUfA1E0 aktH+889EAudIXTuywqz16L9WAV9pC9vYSFB7lXHntaMfxXoqqV7zgEWFpkGV1DUEzdS aDeLohLl3Lwu11Fz6/T9daIv997167VIMhd77nk0GgOPm2rBMqj4gTmXbDs7eKjenhxd YKwQyWq+2/jDa+LRb3U17oEo3PvbaNkDAVim2Y9Lj8t93KRuDcaypH/93lKjv3pXcUTg oACA== X-Gm-Message-State: AOAM531ka4Q/uOk3Hr57GpDRHjkep/B9ag67UmLTCvlAbjUsBUSO2Okk FPg8Zgc9LuHKKvQ2c4ek8HGlOtLrzuuaTxHA2MB+zfkN+dTEFN9niNRh9VAu7c4SPu8io10qPA= = X-Google-Smtp-Source: ABdhPJwQ8y9s1mzQ1PE5nUcAD8wYMhpsT8ExrQ0SY+NPF+/EK05yuwfEssGKPEUcJ1xE3PBGNjvn3g== X-Received: by 2002:a05:6000:104e:: with SMTP id c14mr18581085wrx.130.1632593460311; Sat, 25 Sep 2021 11:11:00 -0700 (PDT) Received: from smtpclient.apple (152.249.143.150.dyn.plus.net. [150.143.249.152]) by smtp.gmail.com with ESMTPSA id j27sm11767784wms.6.2021.09.25.11.10.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Sep 2021 11:10:59 -0700 (PDT) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Sat, 25 Sep 2021 19:10:58 +0100 Message-Id: <7306C2C0-DC84-4A0B-9344-EF238F6A7E44@forgerock.com> References: <2EA892D6-D2F5-46AA-9B03-63F7AC4C5A69@manicode.com> Cc: Dominick Baier , oauth In-Reply-To: <2EA892D6-D2F5-46AA-9B03-63F7AC4C5A69@manicode.com> To: Jim Manico X-Mailer: iPhone Mail (18H17) Content-Type: multipart/alternative; boundary=Apple-Mail-8B4DFE66-6EE9-4916-B807-AA7E67165274 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2021 18:11:10 -0000 --Apple-Mail-8B4DFE66-6EE9-4916-B807-AA7E67165274 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Technically yes, CSRF refers to cross-site attacks. However, there is a cla= ss of attacks that are cross-*origin* but not cross-site and which are othe= rwise identical to CSRF. SameSite doesn=E2=80=99t protect against these att= acks but other traditional CSRF defences *do*. For example, synchronizer to= kens in hidden form fields or even just requiring a custom header on reques= ts both provide some protection against such attacks, as they both use mech= anisms that are subject to the same origin policy rather than same-site.=20 =E2=80=94 Neil > On 25 Sep 2021, at 18:20, Jim Manico wrote: >=20 > =EF=BB=BFIf someone has taken over a subdomain in the ways described, tha= t is not cross site request forgery since the attack is occurring from with= in your site. It=E2=80=99s more likely XSS that allows for cookie clobberin= g or similar, or just malicious code injected by the malicious controller o= f your subdomain. This is not strictly CSRF nor are these problems protecte= d from any other standard form of CSRF defense. >=20 > CSRF is Cross Site attack where the attack is hosted on a different domai= n.=20 >=20 > -- > Jim Manico >=20 >>> On Sep 25, 2021, at 1:07 AM, Dominick Baier = wrote: >>>=20 >> =EF=BB=BF >> In 6.1 it says >>=20 >> "Additionally, the SameSite cookie attribute can be used to=09 >> prevent CSRF attacks, or alternatively, the application and API cou= ld=09 >> be written to use anti-CSRF tokens.=E2=80=9D >>=20 >> =E2=80=9CPrevent=E2=80=9D is a bit strong. >>=20 >> SameSite only restricts cookies sent across site boundaries Iit does not= prevent CSRF attacks from within a site boundary. Scenarios could be a com= promised sub-domain, like sub-domain takeover or just some vulnerable appli= cation co-located on the same site. >>=20 >> thanks >> =E2=80=94=E2=80=94=E2=80=94 >> Dominick Baier >> _______________________________________________ >> 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 Manage My Preferences , Unsubscribe=20 --Apple-Mail-8B4DFE66-6EE9-4916-B807-AA7E67165274 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Technically yes, CSRF = refers to cross-site attacks. However, there is a class of attacks that are= cross-*origin* but not cross-site and which are otherwise identical to CSR= F. SameSite doesn=E2=80=99t protect against these attacks but other traditi= onal CSRF defences *do*. For example, synchronizer tokens in hidden form fi= elds or even just requiring a custom header on requests both provide some p= rotection against such attacks, as they both use mechanisms that are subjec= t to the same origin policy rather than same-site. 

=E2=80=94 Neil

On 25 Sep 2021, at 18:20, Jim Manico <jim@manicod= e.com> wrote:

=EF=BB=BFIf someone has taken over a subdomain in the ways describ= ed, that is not cross site request forgery since the attack is occurring fr= om within your site. It=E2=80=99s more likely XSS that allows for cookie cl= obbering or similar, or just malicious code injected by the malicious contr= oller of your subdomain. This is not strictly CSRF nor are these problems p= rotected from any other standard form of CSRF defense.

<= div>CSRF is Cross Site attack where the attack is hosted on a different dom= ain. 

--
Jim Manico
=

On Sep 25, 2021, at 1:07 AM,= Dominick Baier <dbaier@leastprivilege.com> wrote:

=EF=BB=BF
In 6.1 it says

"Additionally,= the SameSite cookie attribute can be used to
    prev= ent CSRF attacks, or alternatively, the application and API could
 =   be written to use anti-CSRF tokens.=E2=80=9D

=E2=80=9CPrevent=E2=80= =9D is a bit strong.

SameSite only restricts cookies sent across site boundaries Ii= t does not prevent CSRF attacks from within a site boundary. Scenarios coul= d be a compromised sub-domain, like sub-domain takeover or just some vulner= able application co-located on the same site.

thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Ba= ier
_______________________________________________
OAuth= mailing list
OAuth@ietf.org
https://www.ie= tf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.o= rg/mailman/listinfo/oauth

Manage My Preferences, Unsubscribe
--Apple-Mail-8B4DFE66-6EE9-4916-B807-AA7E67165274-- From nobody Sat Sep 25 15:04:43 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F783A0138 for ; Sat, 25 Sep 2021 15:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FZzYtVxlYfOg for ; Sat, 25 Sep 2021 15:04:37 -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 1C7CE3A012A for ; Sat, 25 Sep 2021 15:04:37 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id d21so38595065wra.12 for ; Sat, 25 Sep 2021 15:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s8+cC0IZLWHz6Af2BSyMMYaWUUdaSuu98X/GidUaJtw=; b=jNK+mUE4iMQ1KH6i33FgfYrdJhV0zZkHIWtw12DgTK9XrCxY1aIRSp1r3tE4/pWD7R MlKPlGDNkkKzU3YZw083CdPh+tjdcllgY17yRVUY0WTfAOvriqw4cSLOnMJ79LOOuhL0 xr0d+1BDddwavnbVAs3z4LmxJPE8DSQu/6WV6jJyESPMjp9mT6esBC2+Eew1np/YlHs4 XVhM1EjSSuRb+xA1hOsyWLdYdnypxB8DMlmhwwFaTW65YLxEINPJV0pStauSVfSq7dWj yD5FtzQudJ4l+CZMPrK4//KeuJQB3Il2EjKj268v4ioH7/UaywEo+WdaMmjcQVFtWLV9 9G3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s8+cC0IZLWHz6Af2BSyMMYaWUUdaSuu98X/GidUaJtw=; b=6H+97LkTK/CG0ywICCK6RP0SDOWYgJzJhvKSSxV/ET1YX6RCoXpQvxqHeNwUMXhjRG Cs/1tydKucoUWXAXKuKBj8tknEMizbCHlJYPcPnbAjJaOoPD5voBnVZlf3qE6hOJqrVZ pCUyYf8ae1L495VRYCXbUjse5i7sx2EjQ/Ek3yhYqwP1hJ8+psjveSDSyhngZZtwiSg8 jwVG8OLcbXZZh+A51qtRNf7SmXRwFNvTSeTE3FigHiN+/H9dIW5f+LMZZhqXhypNnaRi TNXVxg0XJddlK6DCsVkPZtdWoCLGWuZkeGeIC75Aq/fG80LoDCH+sQoySygC6U4NjpOz IAsg== X-Gm-Message-State: AOAM533D8UVSS4qd4LXfhlEJDY8Cx1ch4Jkd3Uc/9MZpkpz4mIaQbs9D Tq19KQt+eYmbDWvGJxD7mEooZLAMKZozhQP9D4A= X-Google-Smtp-Source: ABdhPJyaMSGz5YV1a3hDLcpmgDg96hQ/ktzNYyJ+0pTlSWfP9EicBidt9rA6sjL3qxW5eB2x7q9DS+gydLB7gKqeQ8Y= X-Received: by 2002:a1c:9a8e:: with SMTP id c136mr8592456wme.191.1632607473577; Sat, 25 Sep 2021 15:04:33 -0700 (PDT) MIME-Version: 1.0 References: <89921372-8c16-3eeb-406f-f55666088e93@hackmanit.de> In-Reply-To: <89921372-8c16-3eeb-406f-f55666088e93@hackmanit.de> From: Rifaat Shekh-Yusef Date: Sat, 25 Sep 2021 18:04:22 -0400 Message-ID: To: Karsten Meyer zu Selhausen Cc: oauth Content-Type: multipart/alternative; boundary="00000000000085326d05ccd90c41" Archived-At: Subject: Re: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification X-BeenThere: oauth@ietf.org X-Mailman-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, 25 Sep 2021 22:04:42 -0000 --00000000000085326d05ccd90c41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Karsten, Daniel, Can you please address my comments in a new version of the draft to allow me to progress it? Regards, Rifaat On Mon, Sep 6, 2021 at 6:50 AM Karsten Meyer zu Selhausen < karsten.meyerzuselhausen@hackmanit.de> wrote: > Hi Rifaat, > > thank you for the shepherd's review. > > Those are valid comments. We will have a second look on this paragraph. > > Best regards, > Karsten > On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote: > > Hi Karsten, Daniel, > > As the document shepherd, I have reviewed the document and I have the > following comments on draft-ietf-oauth-iss-auth-resp-01 version: > > > Section 2.4, paragraph 3, first sentence: > > "If clients interact with both authorization servers supporting this > specification and authorization servers not supporting this > specification, clients SHOULD store the information which > authorization server supports the "iss" parameter." > > Why is this a SHOULD? > > > "Clients MUST > reject authorization responses without the "iss" parameter from > authorization servers which do support the parameter according to the > client's configuration." > > What should the client do when it receives a response with "iss" paramete= r > from an authorization server that did not indicate its support for this > parameter? > > > Section 7 > > RFC6479 should be replaced with *RFC6749* > > > Regards, > Rifaat > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > -- > Karsten Meyer zu Selhausen > Senior IT Security Consultant > Phone: +49 (0)234 / 54456499 > Web: https://hackmanit.de | IT Security Consulting, Penetration Testing, = Security Training > > Is your OAuth or OpenID Connect application vulnerable to mix-up attacks?= Find out more on our blog:https://www.hackmanit.de/en/blog-en/132-how-to-p= rotect-your-oauth-client-against-mix-up-attacks > > Hackmanit GmbH > Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus) > 44789 Bochum > > Registergericht: Amtsgericht Bochum, HRB 14896 > Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj S= omorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz > > --00000000000085326d05ccd90c41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Karsten, Daniel,

Can you please address= my comments in a new version of the draft to allow me to progress=C2=A0it?=

Regards,
=C2=A0Rifaat


On Mon, Sep 6, 2021 at 6:50 AM Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hac= kmanit.de> wrote:
=20 =20 =20

Hi Rifaat,

thank you for the shepherd's review.

Those are valid comments. We will have a second look on this paragraph.

Best regards,
Karsten

On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote:
=20
Hi=C2=A0Karsten, Daniel,

As the document shepherd, I have reviewed the document and I have the following comments on=C2=A0draft-ietf-oauth-iss-auth-resp-= 01 version:


Section 2.4, paragraph 3, first sentence:

"If clients interact with both authorization servers supporting this
=C2=A0 =C2=A0specification and authorization servers not supporti= ng this
=C2=A0 =C2=A0specification, clients SHOULD store the information = which
=C2=A0 =C2=A0authorization server supports the "iss" pa= rameter."
=C2=A0 =C2=A0
Why is this a SHOULD?


"Clients MUST
=C2=A0 =C2=A0reject authorization responses without the "iss= " parameter from
=C2=A0 =C2=A0authorization servers which do support the parameter according to the
=C2=A0 =C2=A0client's configuration."
=C2=A0 =C2=A0
What should the client do when it receives a response with "iss" parameter
from an authorization server that did not indicate its support for this parameter?


Section 7

RFC6479 should be replaced with RFC6749


Regards,=C2=A0
=C2=A0 Rifaat=C2=A0=C2=A0

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

--=20
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.d=
e | IT Security Consulting, Penetration Testing, Security Training

Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? F=
ind out more on our blog:
https://www.hackmanit.de=
/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks

Hackmanit GmbH
Universit=C3=A4tsstra=C3=9Fe 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Gesch=C3=A4ftsf=C3=BChrer: Prof. Dr. J=C3=B6rg Schwenk, Prof. Dr. Juraj Som=
orovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz
--00000000000085326d05ccd90c41-- From nobody Sat Sep 25 15:15:49 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1133A07B8 for ; Sat, 25 Sep 2021 15:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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=manicode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyhkLQ07p3pP for ; Sat, 25 Sep 2021 15:15:41 -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 E1C743A07B6 for ; Sat, 25 Sep 2021 15:15:41 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id g2so8000147pfc.6 for ; Sat, 25 Sep 2021 15:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=message-id:date:mime-version:user-agent:content-language:to:cc :references:from:subject:in-reply-to; bh=R82QBlQrFPFuDY8W/p86N8AaRb9W96SEwR5K0KhnnIo=; b=Eho6D0BrdPNEShuP7vqWwnM8MK0IJry/0oYK+4V8vs9xZau+F/4JTGkOgoOwZAVO+3 erA93DI9ZrEAaYRkhsjKRIVpWyfSHOtmpbtG/npPFnw0loN/jhIcjWomU/bLSloC89d3 Xw4ZYt0R65WRCwcbLfyr4ga8ZXRsiHPfCHZWCFfGfqKxwIkaw8kmoh+8FtJ28JahKO7z qPawHQkuwAx5P8Bz7KbTBBWhCzinRNeEGNRSUSLDFYHD5pifl3VDnAZ4A7zr7VuHTiip 9ROKERFeolbv+N7BxRx4hFFExGJbS7recnDh4fswz+YEZHfKqdDqFkptMQp+HUAxBmbL GYnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:subject:in-reply-to; bh=R82QBlQrFPFuDY8W/p86N8AaRb9W96SEwR5K0KhnnIo=; b=zOXqm2wnpsJ6CetW1lmfKcmhx+z9u5V2RRh5chNRdMCJq010g8mTFGNEezXqE6bZCN QDLMFrcZ6Ykq+oFj1haraPZTgTJRSW7gofTbMzWTrAIbSXTdG5V/SdxyXilcv1CWOxNB EZLAJX0kNie5dgdPZLyLza1zQcrOidC9u53ceSD8BwNuu9q27BLBaBlTLBfpHiGd0rCp sl62ti1YOExV+r9+8Gfxn59JswhBWxK4Mygv5sw7s/5Ae+Fxc9+L//WRSyAcCCCseaJk vsmnZmfSu8Jtli+gbr0k3TT02CPwSsZnJ3ePGnge80qWS87vWNGMZEQlcqTLGDQcdkF3 6ZtA== X-Gm-Message-State: AOAM533db1ICnY6NstA9MaymMOW70G2iA7iUc9pDlSqzmleqKd4eOhN1 qQOnlUrO9V4MvH/P46nsGJaeQQ== X-Google-Smtp-Source: ABdhPJzcFXd8YV7zdqUbXhOga8gUdqMEjP+DHEL5z8yRHPScos/ugFJNoxztegqrIu5opsfDQCthWg== X-Received: by 2002:a65:44c4:: with SMTP id g4mr9944030pgs.254.1632608140524; Sat, 25 Sep 2021 15:15:40 -0700 (PDT) Received: from [192.168.86.41] (204-210-127-015.res.spectrum.com. [204.210.127.15]) by smtp.googlemail.com with ESMTPSA id x15sm13915581pgt.34.2021.09.25.15.15.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Sep 2021 15:15:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------ANiAJ0VplaxbFIWG5BQiDZc5" Message-ID: <8645e6a3-6c23-05f0-2165-579d502109b7@manicode.com> Date: Sat, 25 Sep 2021 12:15:38 -1000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 Content-Language: en-US To: Neil Madden Cc: Dominick Baier , oauth References: <2EA892D6-D2F5-46AA-9B03-63F7AC4C5A69@manicode.com> <7306C2C0-DC84-4A0B-9344-EF238F6A7E44@forgerock.com> From: Jim Manico In-Reply-To: <7306C2C0-DC84-4A0B-9344-EF238F6A7E44@forgerock.com> Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2021 22:15:47 -0000 This is a multi-part message in MIME format. --------------ANiAJ0VplaxbFIWG5BQiDZc5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Neil! =) I get your point! I would suggest this text be written as something along the lines of: "Additionally, the SameSite cookie attribute can be used to   prevent CSRF attacks /*but the application and API should*//*also*/ /**//**//*  be written to use */anti-CSRF tokens for stateful session-based applications           or use of the double-cookie submit pattern for stateless applications.”' PS: If an adversary controls a subdomain can't they clobber and over-write root level cookies anyhow? I do not think CSRF defense will defeat an adversarial subdomains ability to over-write a cookie and circumvent double-cookie-submit. On 9/25/21 8:10 AM, Neil Madden wrote: > Technically yes, CSRF refers to cross-site attacks. However, there is > a class of attacks that are cross-*origin* but not cross-site and > which are otherwise identical to CSRF. SameSite doesn’t protect > against these attacks but other traditional CSRF defences *do*. For > example, synchronizer tokens in hidden form fields or even just > requiring a custom header on requests both provide some protection > against such attacks, as they both use mechanisms that are subject to > the same origin policy rather than same-site. > > — Neil > >> On 25 Sep 2021, at 18:20, Jim Manico wrote: >> >>  If someone has taken over a subdomain in the ways described, that >> is not cross site request forgery since the attack is occurring from >> within your site. It’s more likely XSS that allows for cookie >> clobbering or similar, or just malicious code injected by the >> malicious controller of your subdomain. This is not strictly CSRF nor >> are these problems protected from any other standard form of CSRF >> defense. >> >> CSRF is Cross Site attack where the attack is hosted on a different >> domain. >> >> -- >> Jim Manico >> >>> On Sep 25, 2021, at 1:07 AM, Dominick Baier >>> wrote: >>> >>>  >>> In 6.1 it says >>> >>> "Additionally, the SameSite cookie attribute can be used to >>>   prevent CSRF attacks, or alternatively, the application and API could >>>   be written to use anti-CSRF tokens.” >>> >>> “Prevent” is a bit strong. >>> >>> SameSite only restricts cookies sent across site boundaries Iit does >>> not prevent CSRF attacks from within a site boundary. Scenarios >>> could be a compromised sub-domain, like sub-domain takeover or just >>> some vulnerable application co-located on the same site. >>> >>> thanks >>> ——— >>> Dominick Baier >>> _______________________________________________ >>> 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 > > Manage My Preferences , > Unsubscribe > -- Jim Manico Manicode Security https://www.manicode.com --------------ANiAJ0VplaxbFIWG5BQiDZc5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi Neil! =)

I get your point!

I would suggest this text be written as something along the lines of:

"Additionally, the SameSite cookie attribute can be used to
    prevent CSRF attacks but the application and API should also
    be written to use anti-CSRF tokens for stateful session-based applications
          or use of the double-cookie submit pattern for stateless applications.”'

PS: If an adversary controls a subdomain can't they clobber and over-write root level cookies anyhow? I do not think CSRF defense will defeat an adversarial subdomains ability to over-write a cookie and circumvent double-cookie-submit.

On 9/25/21 8:10 AM, Neil Madden wrote:
Technically yes, CSRF refers to cross-site attacks. However, there is a class of attacks that are cross-*origin* but not cross-site and which are otherwise identical to CSRF. SameSite doesn’t protect against these attacks but other traditional CSRF defences *do*. For example, synchronizer tokens in hidden form fields or even just requiring a custom header on requests both provide some protection against such attacks, as they both use mechanisms that are subject to the same origin policy rather than same-site. 

— Neil

On 25 Sep 2021, at 18:20, Jim Manico <jim@manicode.com> wrote:

 If someone has taken over a subdomain in the ways described, that is not cross site request forgery since the attack is occurring from within your site. It’s more likely XSS that allows for cookie clobbering or similar, or just malicious code injected by the malicious controller of your subdomain. This is not strictly CSRF nor are these problems protected from any other standard form of CSRF defense.

CSRF is Cross Site attack where the attack is hosted on a different domain. 

--
Jim Manico

On Sep 25, 2021, at 1:07 AM, Dominick Baier <dbaier@leastprivilege.com> wrote:


In 6.1 it says

"Additionally, the SameSite cookie attribute can be used to
    prevent CSRF attacks, or alternatively, the application and API could
    be written to use anti-CSRF tokens.”

“Prevent” is a bit strong.

SameSite only restricts cookies sent across site boundaries Iit does not prevent CSRF attacks from within a site boundary. Scenarios could be a compromised sub-domain, like sub-domain takeover or just some vulnerable application co-located on the same site.

thanks
———
Dominick Baier
_______________________________________________
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


-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------ANiAJ0VplaxbFIWG5BQiDZc5-- From nobody Sat Sep 25 23:30:33 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DFC3A102B for ; Sat, 25 Sep 2021 23:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pragmaticwebsecurity.com header.b=jJ32GE5d; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EK7/fV+N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86MoyVvRYnCn for ; Sat, 25 Sep 2021 23:30:25 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28173A102E for ; Sat, 25 Sep 2021 23:30:24 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9015D5C00C1; Sun, 26 Sep 2021 02:30:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 26 Sep 2021 02:30:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= pragmaticwebsecurity.com; h=from:message-id:content-type :mime-version:subject:date:in-reply-to:cc:to:references; s=fm2; bh=P0b6mfu2iNpMBJw5ef9nxbMmrz+5pMZ8lohM/A/KTag=; b=jJ32GE5dYoSR 3q9i+kurwOxgehkJibk2WuV0hL2Yr4nAgkYg4WtpEXKH1xx3ztU1ghaeT+q7PJlA 2NgijaF2ULXbtx8qOp3q31fcyoCgaydF/Cmk/dDYiacqpM4M6mELVD4ZfWMpiraE V4OPlZREhJiruQ1WxP12SPSaLFf8g7GQB9hRP+MNLMTx45rlg8f8ATo79C2OqNYc N+RcNiYEYi+mh8oKWx9g9nJOdf0Ecr2cejd37HT6+z1BTwCzylhMnNzdm1TWqyf0 aXlKqg5wW7hmBN83imrfAOJGUyfAzhUGLyZ61MTz/ga1CnSs8NznNn6KVdn831kG aBx6DxOyFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=P0b6mf u2iNpMBJw5ef9nxbMmrz+5pMZ8lohM/A/KTag=; b=EK7/fV+NLs/oaXeQfmlXuG MYP6BTNiHZ8iyObu6VLv/ZmlgF0WSxih9wqLWh5tFLjf++t2uLn82m0NfU6PbIQW pxSnA0TuVSqQ++AEJ4ecYR8eoTknHRPRfyimOx+7aluKVEjzAlY3XG3iTnOPg/3m O6uuGcXGgPIf6sY4YmAQEEKKBP54F/hNXqGCToms2u/WWPIlqiVk7AGPlhd27Quz qXqA38dj6Uswoq+xrEGe17CrqhlOn5gytGKVlTVzgOHwU8e3rTAqJH7kTjYdGcMa 0A2xn50TiryEyMXL4mGSw/jdCXV2Lq54vY1KgKCkD72BeY6Wj2qCzvT2PxAO2dLA == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejhedgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpefrhhhilhhi phhpvgcuffgvucfthigtkhcuoehphhhilhhiphhpvgesphhrrghgmhgrthhitgifvggssh gvtghurhhithihrdgtohhmqeenucggtffrrghtthgvrhhnpeekgfffkeehveekkeekkeef keelgfeihfeijeffieejgefhheetkedvudehvdetgfenucffohhmrghinhepphhrrghgmh grthhitgifvggsshgvtghurhhithihrdgtohhmpdhivghtfhdrohhrghdpfhhorhhgvghr ohgtkhdrtghomhdpmhgrnhhitghouggvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepphhhihhlihhpphgvsehprhgrghhmrghtihgt figvsghsvggtuhhrihhthidrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 26 Sep 2021 02:30:19 -0400 (EDT) From: Philippe De Ryck Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_13CFCB1A-7A07-4905-AAD3-BDD5AD0C18B6" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Sun, 26 Sep 2021 08:30:17 +0200 In-Reply-To: <8645e6a3-6c23-05f0-2165-579d502109b7@manicode.com> Cc: Neil Madden , oauth To: Jim Manico References: <2EA892D6-D2F5-46AA-9B03-63F7AC4C5A69@manicode.com> <7306C2C0-DC84-4A0B-9344-EF238F6A7E44@forgerock.com> <8645e6a3-6c23-05f0-2165-579d502109b7@manicode.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 06:30:31 -0000 --Apple-Mail=_13CFCB1A-7A07-4905-AAD3-BDD5AD0C18B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That=E2=80=99s why cookies should be set with the __Host- prefix.=20 In a carefully-designed API, CORS will function as a CSRF defense, even = when the attacker is controlling a subdomain or sibling domain.=20 Overall, I think the first part of 6.1 makes sense, but I don=E2=80=99t = think the document should try to draw out such an architecture in 1 or 2 = paragraphs at the end of that section. Philippe =E2=80=94 Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com > On 26 Sep 2021, at 00:15, Jim Manico wrote: >=20 > Hi Neil! =3D) >=20 > I get your point!=20 > I would suggest this text be written as something along the lines of: >=20 > "Additionally, the SameSite cookie attribute can be used to=09 > prevent CSRF attacks but the application and API should = also > be written to use anti-CSRF tokens for stateful session-based = applications=20 > or use of the double-cookie submit pattern for stateless = applications.=E2=80=9D' >=20 > PS: If an adversary controls a subdomain can't they clobber and = over-write root level cookies anyhow? I do not think CSRF defense will = defeat an adversarial subdomains ability to over-write a cookie and = circumvent double-cookie-submit.=20 >=20 > On 9/25/21 8:10 AM, Neil Madden wrote: >> Technically yes, CSRF refers to cross-site attacks. However, there is = a class of attacks that are cross-*origin* but not cross-site and which = are otherwise identical to CSRF. SameSite doesn=E2=80=99t protect = against these attacks but other traditional CSRF defences *do*. For = example, synchronizer tokens in hidden form fields or even just = requiring a custom header on requests both provide some protection = against such attacks, as they both use mechanisms that are subject to = the same origin policy rather than same-site.=20 >>=20 >> =E2=80=94 Neil >>=20 >>> On 25 Sep 2021, at 18:20, Jim Manico = wrote: >>>=20 >>> =EF=BB=BF If someone has taken over a subdomain in the ways = described, that is not cross site request forgery since the attack is = occurring from within your site. It=E2=80=99s more likely XSS that = allows for cookie clobbering or similar, or just malicious code injected = by the malicious controller of your subdomain. This is not strictly CSRF = nor are these problems protected from any other standard form of CSRF = defense. >>>=20 >>> CSRF is Cross Site attack where the attack is hosted on a different = domain.=20 >>>=20 >>> -- >>> Jim Manico >>>=20 >>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier = wrote: >>>>=20 >>>> =EF=BB=BF >>>> In 6.1 it says >>>>=20 >>>> "Additionally, the SameSite cookie attribute can be used to=09 >>>> prevent CSRF attacks, or alternatively, the application and = API could=09 >>>> be written to use anti-CSRF tokens.=E2=80=9D >>>>=20 >>>> =E2=80=9CPrevent=E2=80=9D is a bit strong. >>>>=20 >>>> SameSite only restricts cookies sent across site boundaries Iit = does not prevent CSRF attacks from within a site boundary. Scenarios = could be a compromised sub-domain, like sub-domain takeover or just some = vulnerable application co-located on the same site. >>>>=20 >>>> thanks >>>> =E2=80=94=E2=80=94=E2=80=94 >>>> Dominick Baier >>>> _______________________________________________ >>>> 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 >> Manage My Preferences , = Unsubscribe > --=20 > Jim Manico > Manicode Security > https://www.manicode.com = _______________________________________________= > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_13CFCB1A-7A07-4905-AAD3-BDD5AD0C18B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That=E2=80=99s why cookies should be set with the __Host- = prefix. 

In a = carefully-designed API, CORS will function as a CSRF defense, even when = the attacker is controlling a subdomain or sibling = domain. 

Overall, I think the first part of 6.1 makes sense, but I = don=E2=80=99t think the document should try to draw out such an = architecture in 1 or 2 paragraphs at the end of that section.

Philippe

=E2=80=94
Pragmatic Web Security
Security= for developers
https://pragmaticwebsecurity.com

On 26 Sep 2021, at 00:15, Jim Manico <jim@manicode.com> = wrote:

Hi Neil! =3D)

I get your point! 

I = would suggest this text be written as something along the lines = of:

"Additionally, the SameSite = cookie attribute can be used to
     prevent CSRF = attacks but the application and API should = also
  =    be written to = use anti-CSRF = tokens for stateful session-based applications 
          or use = of the double-cookie submit pattern for stateless = applications.=E2=80=9D'

PS: If an adversary controls a subdomain can't they clobber = and over-write root level cookies anyhow? I do not think CSRF defense = will defeat an adversarial subdomains ability to over-write a cookie and = circumvent double-cookie-submit. 

On 9/25/21 8:10 = AM, Neil Madden wrote:
Technically= yes, CSRF refers to cross-site attacks. However, there is a class of = attacks that are cross-*origin* but not cross-site and which are = otherwise identical to CSRF. SameSite doesn=E2=80=99t protect against = these attacks but other traditional CSRF defences *do*. For example, = synchronizer tokens in hidden form fields or even just requiring a = custom header on requests both provide some protection against such = attacks, as they both use mechanisms that are subject to the same origin = policy rather than same-site. 

=E2=80=94 Neil

On 25 Sep 2021, at 18:20, Jim Manico <jim@manicode.com> wrote:

=EF=BB=BF If someone has taken over a = subdomain in the ways described, that is not cross site request forgery = since the attack is occurring from within your site. It=E2=80=99s more = likely XSS that allows for cookie clobbering or similar, or just = malicious code injected by the malicious controller of your subdomain. = This is not strictly CSRF nor are these problems protected from any = other standard form of CSRF defense.

CSRF is Cross Site attack where the = attack is hosted on a different domain. 

--
Jim Manico

On Sep 25, 2021, at 1:07 = AM, Dominick Baier <dbaier@leastprivilege.com>= ; wrote:

=EF=BB=BF
In 6.1 it says

"Additionally, the SameSite cookie attribute can be = used to =
     prevent CSRF attacks, or = alternatively, the application and API could
     be written to use anti-CSRF = tokens.=E2=80=9D

=E2=80=9CPrevent=E2= =80=9D is a bit strong.

SameSite only = restricts cookies sent across site boundaries Iit does not prevent CSRF = attacks from within a site boundary. Scenarios could be a compromised = sub-domain, like sub-domain takeover or just some vulnerable application = co-located on the same site.

thanks
=E2=80=94=E2=80=94=E2=80=94
Dominick Baier
_______________________________________________
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

Manage My Preferences, Unsubscribe
--=20
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_13CFCB1A-7A07-4905-AAD3-BDD5AD0C18B6-- From nobody Sun Sep 26 01:24:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3223A16EB for ; Sun, 26 Sep 2021 01:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 uRF2EthnVjiu for ; Sun, 26 Sep 2021 01:24:29 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAADF3A16E9 for ; Sun, 26 Sep 2021 01:24:28 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id g16so41541418wrb.3 for ; Sun, 26 Sep 2021 01:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=W6OWYVscMgN9dKc4JyjFY0YCcUobf0ujmsTyXO+kgQs=; b=ISVEOMrfGu1QU3qwfMWqDr+pY5SWQOD/pW3aMZFzUob7VQcIJvHb+/jKL8yf3v3RPN XufRw/0W1lc0PISSZmSRvv6lz3CwHntL2U8aStJGxiya8pqv6eCU3nVdm1LJE+ok6ykm AEtoWe50/kWUXCZBwRnshks/GQFgRDWXka0kA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=W6OWYVscMgN9dKc4JyjFY0YCcUobf0ujmsTyXO+kgQs=; b=GV4kFFmhjPmBDAoFrVmNnZr9lVDB5jhi9Hjo3K9xIyew4Rv1sUMpmmu8AzAfz79YRq nPic8NpjOIEgC4OwfKZXtiwcjNVq1DJ8fNLb48HxJletO9Sr3EsH1hMYA/uSqBd8/qqa uIPIKTp8Oj2cGqnqDRnIoS+A+zGl+6ppBdwPawC5q3eqB++EYlAwsQzM6pmLqd2y0OWG G2amKslMCHeN/51BKlmKWHMy73QJGcacFMiZeMAMjMlCos5b19LCdHQ1SEOXZTSAnfDN FX64txQYM8UORUik2vuoxfNgxrZUB7hYJFUeUEyAjTSrmX28wOY+IbSVAl3hRhSCKIlF NCOA== X-Gm-Message-State: AOAM5312QyH3cqElO+PwePCXdCT5jXj8up6JcCOZemmeJYvnPJGh561o LE1FDTySExJZnWxtm3oU0X6FBCcH5DiR6h2ZgXUpHx0O0+igxUcPYWBWUjvp1qIvv1Bcs/+Farf 10Z3WTHGJm3TFGGMmBZ1Ovi09S23io+B1ACAI0hjXARNBOQ9mvgB48xwsg0xk/V9eOA== X-Google-Smtp-Source: ABdhPJwoFZWZEddUOdaXGtUcHJEDxHnFbQtdm+6abCaz41NgyiXPmVANTgo2EzIa+cfE9+OCCZBjKQ== X-Received: by 2002:a7b:cbce:: with SMTP id n14mr10335681wmi.169.1632644666776; Sun, 26 Sep 2021 01:24:26 -0700 (PDT) Received: from smtpclient.apple (152.249.143.150.dyn.plus.net. [150.143.249.152]) by smtp.gmail.com with ESMTPSA id i2sm12920666wrq.78.2021.09.26.01.24.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Sep 2021 01:24:26 -0700 (PDT) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Sun, 26 Sep 2021 09:24:25 +0100 Message-Id: <9C0F9B3A-66A8-4C5E-9E5E-C01C919D4A83@forgerock.com> References: Cc: Jim Manico , oauth In-Reply-To: To: Philippe De Ryck X-Mailer: iPhone Mail (18H17) Content-Type: multipart/alternative; boundary=Apple-Mail-7E78CA2E-3710-42BD-B0C9-69D0E6010B74 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 08:24:35 -0000 --Apple-Mail-7E78CA2E-3710-42BD-B0C9-69D0E6010B74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right, cookie prefixes is one approach - but still has a little way to go o= n browser share [1].=20 In my book (have I mentioned my book? :-)), I show a variant of the double-= submit cookie pattern in which the anti-CSRF token is a SHA-256 hash of the= session cookie [2], which prevents the cookie being overridden. We should probably just defer to the security considerations in rfc6265-bis= [3], which already discusses some limitations of SameSite and recommends i= t be used as a defence-in-depth alongside traditional defences.=20 [1]: https://caniuse.com/?search=3Dcookie%20prefix [2]: https://livebook.manning.com/book/api-security-in-action/chapter-4/181 [3]: https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-08.html#name-s= amesite-cookies =E2=80=94 Neil > On 26 Sep 2021, at 07:30, Philippe De Ryck wrote: >=20 > =EF=BB=BFThat=E2=80=99s why cookies should be set with the __Host- prefix= .=20 >=20 > In a carefully-designed API, CORS will function as a CSRF defense, even w= hen the attacker is controlling a subdomain or sibling domain.=20 >=20 > Overall, I think the first part of 6.1 makes sense, but I don=E2=80=99t t= hink the document should try to draw out such an architecture in 1 or 2 par= agraphs at the end of that section. >=20 > Philippe >=20 > =E2=80=94 > Pragmatic Web Security > Security for developers > https://pragmaticwebsecurity.com >=20 >> On 26 Sep 2021, at 00:15, Jim Manico wrote: >>=20 >> Hi Neil! =3D) >>=20 >> I get your point!=20 >> I would suggest this text be written as something along the lines of: >>=20 >> "Additionally, the SameSite cookie attribute can be used to=09 >> prevent CSRF attacks but the application and API should also >> be written to use anti-CSRF tokens for stateful session-based appli= cations=20 >> or use of the double-cookie submit pattern for stateless appli= cations.=E2=80=9D' >>=20 >> PS: If an adversary controls a subdomain can't they clobber and over-wri= te root level cookies anyhow? I do not think CSRF defense will defeat an ad= versarial subdomains ability to over-write a cookie and circumvent double-c= ookie-submit.=20 >>=20 >>> On 9/25/21 8:10 AM, Neil Madden wrote: >>> Technically yes, CSRF refers to cross-site attacks. However, there is a= class of attacks that are cross-*origin* but not cross-site and which are = otherwise identical to CSRF. SameSite doesn=E2=80=99t protect against these= attacks but other traditional CSRF defences *do*. For example, synchronize= r tokens in hidden form fields or even just requiring a custom header on re= quests both provide some protection against such attacks, as they both use = mechanisms that are subject to the same origin policy rather than same-site= .=20 >>>=20 >>> =E2=80=94 Neil >>>=20 >>>>> On 25 Sep 2021, at 18:20, Jim Manico wrote: >>>>>=20 >>>> =EF=BB=BF If someone has taken over a subdomain in the ways described,= that is not cross site request forgery since the attack is occurring from = within your site. It=E2=80=99s more likely XSS that allows for cookie clobb= ering or similar, or just malicious code injected by the malicious controll= er of your subdomain. This is not strictly CSRF nor are these problems prot= ected from any other standard form of CSRF defense. >>>>=20 >>>> CSRF is Cross Site attack where the attack is hosted on a different do= main.=20 >>>>=20 >>>> -- >>>> Jim Manico >>>>=20 >>>>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier wrote: >>>>>>=20 >>>>> =EF=BB=BF >>>>> In 6.1 it says >>>>>=20 >>>>> "Additionally, the SameSite cookie attribute can be used to=09 >>>>> prevent CSRF attacks, or alternatively, the application and API = could=09 >>>>> be written to use anti-CSRF tokens.=E2=80=9D >>>>>=20 >>>>> =E2=80=9CPrevent=E2=80=9D is a bit strong. >>>>>=20 >>>>> SameSite only restricts cookies sent across site boundaries Iit does = not prevent CSRF attacks from within a site boundary. Scenarios could be a = compromised sub-domain, like sub-domain takeover or just some vulnerable ap= plication co-located on the same site. >>>>>=20 >>>>> thanks >>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>> Dominick Baier >>>>> _______________________________________________ >>>>> 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 >>> Manage My Preferences, Unsubscribe >>>=20 >> --=20 >> Jim Manico >> Manicode Security >> https://www.manicode.com >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --=20 Manage My Preferences , Unsubscribe=20 --Apple-Mail-7E78CA2E-3710-42BD-B0C9-69D0E6010B74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, cookie prefixes= is one approach - but still has a little way to go on browser share [1].&n= bsp;

In my book (have I me= ntioned my book? :-)), I show a variant of the double-submit cookie pattern= in which the anti-CSRF token is a SHA-256 hash of the session cookie [2], = which prevents the cookie being overridden.

We should probably just defer to the security considerati= ons in rfc6265-bis [3], which already discusses some limitations of SameSit= e and recommends it be used as a defence-in-depth alongside traditional def= ences. 

=

=E2=80=94 Neil

On 26 Sep 2021, at 07:30, Philippe De Ryck &= lt;philippe@pragmaticwebsecurity.com> wrote:

<= blockquote type=3D"cite">
=EF=BB=BFThat=E2=80=99s why cookies= should be set with the __Host- prefix. 

In a carefully-designed API, CORS will function as a= CSRF defense, even when the attacker is controlling a subdomain or sibling= domain. 

Ov= erall, I think the first part of 6.1 makes sense, but I don=E2=80=99t think= the document should try to draw out such an architecture in 1 or 2 paragra= phs at the end of that section.

<= div class=3D"">Philippe

=E2=80=94
Pragmatic Web Security
Security for deve= lopers
https://pragmaticwebsecurity.com

On= 26 Sep 2021, at 00:15, Jim Manico <jim@manicode.com> wrote:

Hi Neil! =3D)

I get you= r point! 

I would= suggest this text be written as something along the lines of:

"Additionally, the SameS= ite cookie attribute can be used to
     prevent = CSRF attacks but the application and API should also=
<= i class=3D"">   &n= bsp; be written to use anti-CSRF tokens for stateful session-based applications 
      =     or use of the double-cookie submit pattern for stateless= applications.=E2=80=9D'

PS: If an adversary controls a subdomain can't they clobber and over= -write root level cookies anyhow? I do not think CSRF defense will defeat a= n adversarial subdomains ability to over-write a cookie and circumvent doub= le-cookie-submit. 

On 9/25= /21 8:10 AM, Neil Madden wrote:
Technically yes, CSRF refers to cross-site attacks. However, = there is a class of attacks that are cross-*origin* but not cross-site and = which are otherwise identical to CSRF. SameSite doesn=E2=80=99t protect aga= inst these attacks but other traditional CSRF defences *do*. For example, s= ynchronizer tokens in hidden form fields or even just requiring a custom he= ader on requests both provide some protection against such attacks, as they= both use mechanisms that are subject to the same origin policy rather than= same-site. 

=E2=80=94 Neil
On 25 Sep 2021, at 18:20,= Jim Manico <jim@manicode.com= > wrote:

=EF=BB=BF If someone has taken over a subdomain in the ways described,= that is not cross site request forgery since the attack is occurring from = within your site. It=E2=80=99s more likely XSS that allows for cookie clobb= ering or similar, or just malicious code injected by the malicious controll= er of your subdomain. This is not strictly CSRF nor are these problems prot= ected from any other standard form of CSRF defense.

CSRF is Cross Site attack wher= e the attack is hosted on a different domain. 

--
J= im Manico

On Sep 25, 2021, at 1:07 AM, Dominick Baier <dbaier@leastprivilege.co= m> wrote:

=EF=BB=BF
In 6.1 it says

"Additionally, the SameSit= e cookie attribute can be used to
 = ;    prevent CSRF attacks, or alternatively, the appli= cation and API could
     be written to use anti-CSRF tokens.=E2=80=9D

=E2=80=9CPrevent=E2=80=9D is a bit strong.

SameSite only restricts cookies sent across site boundaries Iit = does not prevent CSRF attacks from within a site boundary. Scenarios could = be a compromised sub-domain, like sub-domain takeover or just some vulnerab= le application co-located on the same site.

thanks
=E2=80=94= =E2=80=94=E2=80=94
Dominick Baier
_______________________________________________
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

Manage My Preferences,&nbs= p;Unsubscribe

--=20
Jim Manico
Manicode Security
https=
://www.manicode.com
_______________________________________= ________
OAuth mailing = list
OAuth@ietf.orghttps://www= .ietf.org/mailman/listinfo/oauth
=


Manage My Preferences, Unsubscribe
--Apple-Mail-7E78CA2E-3710-42BD-B0C9-69D0E6010B74-- From nobody Sun Sep 26 03:28:55 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1F03A1DF8 for ; Sun, 26 Sep 2021 03:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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=manicode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg3pUh9j0wtY for ; Sun, 26 Sep 2021 03:28:46 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95E33A1DF5 for ; Sun, 26 Sep 2021 03:28:46 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id c1so12975903pfp.10 for ; Sun, 26 Sep 2021 03:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=uFTX8gyl1pxhc0a/YEhW+LPYUhmBXWuaJ+Su0THKSxQ=; b=bp14Pz4/W4taNODJAYv2/+L5FoTjzNv8tMmxpqEZ5WdvG/uHoD3C4OwtxJDztmxOju DoEqbOu3sdqraGEhJqCaf/UqUPlix1Ot32Qto5MHzjmx8Ze8vGa8nADh6j3rgz+rZIUt YrpWw6v+qfqk2VJRnu+g3+HmlX1NGrvyDHfj2vtv7Qw9xfy5lt+B+DobarBGaMdFvRHy WCuEkWIecutUQmQ0fgGQqWEXuw8ZPUP4PxRg31obc6HJMHAAn6P2AuT4zSxzFfTeC16d dZUh5hLj/Qr30KPEWCPSHNXaY60hcl3oWOlbLPYysbLLO+FrGSNOPhFtqYvS1ZikCzIj 79lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=uFTX8gyl1pxhc0a/YEhW+LPYUhmBXWuaJ+Su0THKSxQ=; b=jqthoRQeAmT8MkFcSvoh1zMRxzr/DDvEuqmyYU4dNJ8iWzTlrZWVPmBD2vUZt+bz+a ofP9xAlgswZqp0hJhndCkNgbD/ORiDYQVYZfR7BOgKcdHZPS08t0uHaTVcfe8eGJX33X huXnQi1U4Pm3PMeLTG//n8bEbajlV10GWWGEWxsR06h4ZkrQ1+VJWOWxcrCAiTgeT6Xl pbUx3TAbHBvDoENAC/Ub1JZFZKiNdOcughmSMfqgHlYcgqFFn4dXcx98fNqK/+af2PDI bze1L2zSDvqo01iqDeRd2dEZhyorH5xI6FUEOmAP7YfZZN8VfDZRpTzMZmxR2Pebad49 Ciew== X-Gm-Message-State: AOAM530inQb3oslqKwSy+hoInlv3ouyaY3Lsj/VttI/cZ8vGVCNp0CTi Dx3Bl0f7O1IUCmJCgNBVzm9CuQ== X-Google-Smtp-Source: ABdhPJz5R1duvJUsWNhwPbp82EGpnYZ8Q+S5+rYSnHFyTU42k5YGXhcScaRDm0gQPzSnW5/BHnQ4Pw== X-Received: by 2002:a63:cd48:: with SMTP id a8mr11987169pgj.180.1632652125515; Sun, 26 Sep 2021 03:28:45 -0700 (PDT) Received: from smtpclient.apple (204-210-127-015.res.spectrum.com. [204.210.127.15]) by smtp.gmail.com with ESMTPSA id m28sm15487319pgl.9.2021.09.26.03.28.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Sep 2021 03:28:44 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-7D8A37CD-1851-4C5F-B6EE-93947C73A505 Content-Transfer-Encoding: 7bit From: Jim Manico Mime-Version: 1.0 (1.0) Date: Sun, 26 Sep 2021 00:28:43 -1000 Message-Id: <551F796F-0693-47BA-8A60-15ED2FA5AD7D@manicode.com> References: <9C0F9B3A-66A8-4C5E-9E5E-C01C919D4A83@forgerock.com> Cc: Philippe De Ryck , oauth In-Reply-To: <9C0F9B3A-66A8-4C5E-9E5E-C01C919D4A83@forgerock.com> To: Neil Madden X-Mailer: iPhone Mail (19A346) Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 10:28:53 -0000 --Apple-Mail-7D8A37CD-1851-4C5F-B6EE-93947C73A505 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > That=E2=80=99s why cookies should be set with the __Host- prefix.=20 You can also set the domain of a cookie to actually be a host (subdomain). D= oes that also prevent subdomains from clobbering root directory cookies? PS: I realize this is close to off topic, my last comment on this. - Jim Manico > On Sep 25, 2021, at 10:24 PM, Neil Madden wrot= e: >=20 > =EF=BB=BF > Right, cookie prefixes is one approach - but still has a little way to go o= n browser share [1].=20 >=20 > In my book (have I mentioned my book? :-)), I show a variant of the double= -submit cookie pattern in which the anti-CSRF token is a SHA-256 hash of the= session cookie [2], which prevents the cookie being overridden. >=20 > We should probably just defer to the security considerations in rfc6265-bi= s [3], which already discusses some limitations of SameSite and recommends i= t be used as a defence-in-depth alongside traditional defences.=20 >=20 > [1]: https://caniuse.com/?search=3Dcookie%20prefix > [2]: https://livebook.manning.com/book/api-security-in-action/chapter-4/18= 1 > [3]: https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-08.html#name-= samesite-cookies >=20 > =E2=80=94 Neil >=20 >>> On 26 Sep 2021, at 07:30, Philippe De Ryck wrote: >>>=20 >> =EF=BB=BFThat=E2=80=99s why cookies should be set with the __Host- prefix= .=20 >>=20 >> In a carefully-designed API, CORS will function as a CSRF defense, even w= hen the attacker is controlling a subdomain or sibling domain.=20 >>=20 >> Overall, I think the first part of 6.1 makes sense, but I don=E2=80=99t t= hink the document should try to draw out such an architecture in 1 or 2 para= graphs at the end of that section. >>=20 >> Philippe >>=20 >> =E2=80=94 >> Pragmatic Web Security >> Security for developers >> https://pragmaticwebsecurity.com >>=20 >>> On 26 Sep 2021, at 00:15, Jim Manico wrote: >>>=20 >>> Hi Neil! =3D) >>>=20 >>> I get your point!=20 >>> I would suggest this text be written as something along the lines of: >>>=20 >>> "Additionally, the SameSite cookie attribute can be used to=09 >>> prevent CSRF attacks but the application and API should als= o >>> be written to use anti-CSRF tokens for stateful session-based ap= plications=20 >>> or use of the double-cookie submit pattern for stateless appli= cations.=E2=80=9D' >>>=20 >>> PS: If an adversary controls a subdomain can't they clobber and over-wri= te root level cookies anyhow? I do not think CSRF defense will defeat an adv= ersarial subdomains ability to over-write a cookie and circumvent double-coo= kie-submit.=20 >>>=20 >>>> On 9/25/21 8:10 AM, Neil Madden wrote: >>>> Technically yes, CSRF refers to cross-site attacks. However, there is a= class of attacks that are cross-*origin* but not cross-site and which are o= therwise identical to CSRF. SameSite doesn=E2=80=99t protect against these a= ttacks but other traditional CSRF defences *do*. For example, synchronizer t= okens in hidden form fields or even just requiring a custom header on reques= ts both provide some protection against such attacks, as they both use mecha= nisms that are subject to the same origin policy rather than same-site.=20 >>>>=20 >>>> =E2=80=94 Neil >>>>=20 >>>>>> On 25 Sep 2021, at 18:20, Jim Manico wrote: >>>>>>=20 >>>>> =EF=BB=BF If someone has taken over a subdomain in the ways described,= that is not cross site request forgery since the attack is occurring from w= ithin your site. It=E2=80=99s more likely XSS that allows for cookie clobber= ing or similar, or just malicious code injected by the malicious controller o= f your subdomain. This is not strictly CSRF nor are these problems protected= from any other standard form of CSRF defense. >>>>>=20 >>>>> CSRF is Cross Site attack where the attack is hosted on a different do= main.=20 >>>>>=20 >>>>> -- >>>>> Jim Manico >>>>>=20 >>>>>>> On Sep 25, 2021, at 1:07 AM, Dominick Baier wrote: >>>>>>>=20 >>>>>> =EF=BB=BF >>>>>> In 6.1 it says >>>>>>=20 >>>>>> "Additionally, the SameSite cookie attribute can be used to=09 >>>>>> prevent CSRF attacks, or alternatively, the application a= nd API could=09 >>>>>> be written to use anti-CSRF tokens.=E2=80=9D >>>>>>=20 >>>>>> =E2=80=9CPrevent=E2=80=9D is a bit strong. >>>>>>=20 >>>>>> SameSite only restricts cookies sent across site boundaries Iit does n= ot prevent CSRF attacks from within a site boundary. Scenarios could be a co= mpromised sub-domain, like sub-domain takeover or just some vulnerable appli= cation co-located on the same site. >>>>>>=20 >>>>>> thanks >>>>>> =E2=80=94=E2=80=94=E2=80=94 >>>>>> Dominick Baier >>>>>> _______________________________________________ >>>>>> 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 >>>> Manage My Preferences, Unsubscribe >>>>=20 >>> --=20 >>> Jim Manico >>> Manicode Security >>> https://www.manicode.com >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > Manage My Preferences, Unsubscribe >=20 --Apple-Mail-7D8A37CD-1851-4C5F-B6EE-93947C73A505 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable > That=E2=80=99s why cook= ies should be set with the __Host- prefix. 

You can also set the domain of a cookie to actuall= y be a host (subdomain). Does that also prevent subdomains from clobbering r= oot directory cookies?

PS: I realize this is= close to off topic, my last comment on this.

- Jim Manico


On Sep 25, 2021, at 10:24 PM, Neil Madden <neil.madden@fo= rgerock.com> wrote:

<= div dir=3D"ltr">=EF=BB=BF
Right, cookie prefixes is one approac= h - but still has a little way to go on browser share [1]. 

In my book (have I mentioned my book? := -)), I show a variant of the double-submit cookie pattern in which the anti-= CSRF token is a SHA-256 hash of the session cookie [2], which prevents the c= ookie being overridden.

We s= hould probably just defer to the security considerations in rfc6265-bis [3],= which already discusses some limitations of SameSite and recommends it be u= sed as a defence-in-depth alongside traditional defences. 


=E2=80=94 Neil

On 2= 6 Sep 2021, at 07:30, Philippe De Ryck <philippe@pragmaticwebsecurity.com= > wrote:

=EF=BB=BFThat=E2=80=99s why cookies should be set with the __Host- prefix.=  

In a carefully-de= signed API, CORS will function as a CSRF defense, even when the attacker is c= ontrolling a subdomain or sibling domain. 

Overall, I think the first part of 6.1 makes s= ense, but I don=E2=80=99t think the document should try to draw out such an a= rchitecture in 1 or 2 paragraphs at the end of that section.

Philippe
=E2=80=94
Pragmatic Web Security
Security for develo= pers
https://pragmaticwebsecurity.com

On 2= 6 Sep 2021, at 00:15, Jim Manico <jim@manicode.com> wrote:

Hi Neil! =3D)

I get your point! 

I would suggest this text be writt= en as something along the lines of:

"Additionally, the SameSite cookie attribute can be used to<= span class=3D"Apple-tab-span" style=3D"white-space: pre;">
     prevent CSRF attacks but the application and= API should also
     be written to use anti-CSRF tokens for stateful session-base= d applications 
   =        or use of the double-cookie submit patt= ern for stateless applications.=E2=80=9D'

PS: If an adversary controls a subdomain can't they clobber an= d over-write root level cookies anyhow? I do not think CSRF defense will def= eat an adversarial subdomains ability to over-write a cookie and circumvent d= ouble-cookie-submit. 

On 9/25/21 8:10 A= M, Neil Madden wrote:
Tec= hnically yes, CSRF refers to cross-site attacks. However, there is a class o= f attacks that are cross-*origin* but not cross-site and which are otherwise= identical to CSRF. SameSite doesn=E2=80=99t protect against these attacks b= ut other traditional CSRF defences *do*. For example, synchronizer tokens in= hidden form fields or even just requiring a custom header on requests both p= rovide some protection against such attacks, as they both use mechanisms tha= t are subject to the same origin policy rather than same-site. 

=E2= =80=94 Neil

On 25 Sep 2021, at 18:20, Jim Manico <jim@manicode.com> wrote:

=
=EF=BB= =BF If someone has taken o= ver a subdomain in the ways described, that is not cross site request forger= y since the attack is occurring from within your site. It=E2=80=99s more lik= ely XSS that allows for cookie clobbering or similar, or just malicious code= injected by the malicious controller of your subdomain. This is not strictl= y CSRF nor are these problems protected from any other standard form of CSRF= defense.

CSRF is Cross Site attack where the attack is hosted on a different domain= . 

--
Jim Manico

On Sep 25, 2021, at 1:0= 7 AM, Dominick Baier <= dbaier@leastprivilege.com> = ;wrote:

=EF=BB=BF
In 6.1 it says

"Addition= ally, the SameSite cookie attribute can be used to
     prevent CSRF attacks, or alt= ernatively, the application and API could
 =    be written to use anti-CSRF tokens.=E2= =80=9D

=E2=80=9CPrevent=E2=80=9D is a bit strong= .

SameSite only restricts cookies sent across si= te boundaries Iit does not prevent CSRF attacks from within a site boundary.= Scenarios could be a compromised sub-domain, like sub-domain takeover or ju= st some vulnerable application co-located on the same site.

thanks
= =E2=80=94=E2=80=94=E2=80=94
Dominick Baier
_______________________________________________
OAuth mailing list
OAuth@= ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
<= /div>
_______________________________________________<= /span>
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= Manage My Preferences, Unsubscribe

= 
--=20
Jim Manico
Manicode Security
https:=
//www.manicode.com
______________________________________________= _
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

<= /div>
= --Apple-Mail-7D8A37CD-1851-4C5F-B6EE-93947C73A505-- From nobody Sun Sep 26 05:17:39 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6203A3A21D6 for ; Sun, 26 Sep 2021 05:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 spLuMH_hUunJ for ; Sun, 26 Sep 2021 05:17:32 -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 9B03B3A21D4 for ; Sun, 26 Sep 2021 05:17:32 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id t8so43078012wri.1 for ; Sun, 26 Sep 2021 05:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=btH2b3kpvlN6wHqHg+nsCvst5ZpXmfsCIhpLYd5TGNE=; b=bcGhf61H42DNrjbM5gGXxVF8IRvH0QuI1DNFMRnR/q6UdgYUtPmH4qI78Tj/toUJRz 8aKhCUOyBD1suOpPZXj58p0oZH3dGXd8xIqjVYfYcXhO1D+lUW1gfSPl1MwOv4o25kRK ZqQM4PjtPw81bJ41W46rG2RUq763laxNRzkZQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=btH2b3kpvlN6wHqHg+nsCvst5ZpXmfsCIhpLYd5TGNE=; b=ovnp57pZ18MNsaNW/6uDa/liMmEeR3oF9x+b8HjGq0mvhsDVy3+67DQUOrk1CCwnRM MbOA8zvkXn3Xy6/j8uKlaNvkROarMc8B382JWYyyonS7F/l2LR1/SSs0qXWoW5jd7FU4 kDbHi7RMYbupUju1nSdaq/JCMQoh4hhlG4rA+yNyrU1slZzVlBVt10+QKiccko70VwXG 8tG/Vpys8MdsAyN2Y/fYqVNFJyjCWOaZHFqqtGl5ryx5s5Cl+yrHQNGimYyOgiRc9YPt xhEYFRUNJEZvKPlfSzaQG8SEpP8xfYqgyFTdOR9l/wNlbYcUYkDUo/XnrcsZCScLzPxw KJEQ== X-Gm-Message-State: AOAM532NYYVUPmqMmnb+NU5vIKdG2LCRVEgfDLaM7nUfPJeKWlqs16xN eAR5VKBWayLAWLJ5xyWa5sVTLMtrpgDG3dIIz8oh4jxZ9h8ORS2TG35uQITRfYUcQwDTKsk78ho sosBotw== X-Google-Smtp-Source: ABdhPJxwgk6WCuhk43TfUoLJVjKd3oEcCfUQB0t2ifPAX+EXM9qqmJJA/JhqF3QLxmxpqradNrNjRw== X-Received: by 2002:a5d:6da9:: with SMTP id u9mr22245123wrs.155.1632658649335; Sun, 26 Sep 2021 05:17:29 -0700 (PDT) Received: from smtpclient.apple (152.249.143.150.dyn.plus.net. [150.143.249.152]) by smtp.gmail.com with ESMTPSA id d3sm16410348wrb.36.2021.09.26.05.17.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Sep 2021 05:17:29 -0700 (PDT) From: Neil Madden Mime-Version: 1.0 (1.0) Date: Sun, 26 Sep 2021 13:17:28 +0100 Message-Id: <428175B3-D16B-437B-A602-F39491BCF6E1@forgerock.com> References: <551F796F-0693-47BA-8A60-15ED2FA5AD7D@manicode.com> Cc: Philippe De Ryck , oauth In-Reply-To: <551F796F-0693-47BA-8A60-15ED2FA5AD7D@manicode.com> To: Jim Manico X-Mailer: iPhone Mail (18H17) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 12:17:38 -0000 > On 26 Sep 2021, at 11:28, Jim Manico wrote: >=20 > =EF=BB=BF> That=E2=80=99s why cookies should be set with the __Host- pref= ix.=20 >=20 > You can also set the domain of a cookie to actually be a host (subdomain)= . Does that also prevent subdomains from clobbering root directory cookies No, sadly not. You can set a cookie with domain set to payments.example.com= but then I can hijack foo.example.com and set my own cookie with domain=3D= example.com and the server will be none the wiser.=20 Cheers, Neil --=20 Manage My Preferences , Unsubscribe=20 From nobody Sun Sep 26 06:11:22 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37DA3A2392 for ; Sun, 26 Sep 2021 06:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 1F5-Duf6HtEE for ; Sun, 26 Sep 2021 06:11:16 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E682A3A2391 for ; Sun, 26 Sep 2021 06:11:15 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id w19so14523421ybs.3 for ; Sun, 26 Sep 2021 06:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lEJls/x3EE/NowWdqHE8gM78Nnu/jWMbztVH2ZdHl64=; b=IGo5YZRxo4sd59vPv+K0+3p5cHP1jH+JpZbON0Dj//qTHevpvSAugUVbLPEIXDjSIE EpDltjDHedVsqB+t1ZbX5ZYoSkwJH0aJ2WZKTcGiAp8dlcwNsvZ0ToMRbHWbyViyNqK+ tS5lS7ueSSYNg5OFAacVi1A08YfaYKtueXhMJdcNHiexZBITzA+BiCs/7FcwJxlaf5v5 pT3iLGmdk7t0wKFSg2iw6mYUc3T+5EjyF21gNcneg5ZGePPLPbOXopaUge8XiPFGvlCh 7oldVpz5K8fdngL2GCcmSFk+Mf3SOLrL2e5fzHDwje4nwD45n+FEOSzYIqeA51IJ1y8u QBvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lEJls/x3EE/NowWdqHE8gM78Nnu/jWMbztVH2ZdHl64=; b=c6GlKllfw/DmfHd3MzlsXiJCVfqkUL/NShtB4ds3Va3xZrhMF1Jbu65+DXG9i5ULxO gYuxQot1/XROtWbBt39oteJc73bgTjycDufw9lE6SxnOdqinv93dVQ8o6Uo3i4MueTPt 2ZcU+adTayzrwFrWLnLELVGx+ZSYALd7VGDnPFwMVB+qi1fJWAbV9i3xGrO0XwMUqFxW 0XTl9OyoHQZHWiVmhK8OWIds2VRFKi533ZvgHvdUFxu+ML/Qk2PsJ/QBEgL1W+wlidHc xL/02gXC4qD4gRedA0vfEdD+qGIKGcmqtAVWRrxoiJC1t5OFpepHUmJ1COOX05M2Njb9 OshA== X-Gm-Message-State: AOAM533sqQlGO2irDGcQQdOVXI+Ba9mZj6hAYuqCJx0w0NymtGuSzGBS tQyqmLSmoFUpMiMOoOMAInGrYxNRsUJDbRHkzGw= X-Google-Smtp-Source: ABdhPJyE+bg67XCvEGMSlbUARgK+7w7rtlCyH8gVx9o51M0iWMEG9ek2HCty2XajGHvFXdKlxOBWA5c19GPITtdYse8= X-Received: by 2002:a25:4786:: with SMTP id u128mr24148618yba.539.1632661874949; Sun, 26 Sep 2021 06:11:14 -0700 (PDT) MIME-Version: 1.0 References: <9C0F9B3A-66A8-4C5E-9E5E-C01C919D4A83@forgerock.com> In-Reply-To: <9C0F9B3A-66A8-4C5E-9E5E-C01C919D4A83@forgerock.com> From: Thomas Broyer Date: Sun, 26 Sep 2021 15:11:04 +0200 Message-ID: To: Neil Madden Cc: Philippe De Ryck , oauth Content-Type: multipart/alternative; boundary="00000000000018428905cce5b717" Archived-At: Subject: Re: [OAUTH-WG] Web apps BCP feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2021 13:11:21 -0000 --00000000000018428905cce5b717 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Sep 26, 2021 at 10:24 AM Neil Madden wrote: > Right, cookie prefixes is one approach - but still has a little way to go > on browser share [1]. > Fwiw, a big part of that "missing" browser share is Safari on iOS (14.25% of global share), and I just tested on devices through BrowserStack on https://googlechrome.github.io/samples/cookie-prefixes/ and it *does* support cookie prefixes (tested with v14 and v13). > > In my book (have I mentioned my book? :-)), I show a variant of the > double-submit cookie pattern in which the anti-CSRF token is a SHA-256 ha= sh > of the session cookie [2], which prevents the cookie being overridden. > > We should probably just defer to the security considerations in > rfc6265-bis [3], which already discusses some limitations of SameSite and > recommends it be used as a defence-in-depth alongside traditional defence= s. > +1, just mentioning that there should be CSRF mitigations in place should be enough IMO. Also maybe mention that securing the API is then actually outside the scope of the BCP (whose role in this case is only to recommend *not* using OAuth) --=20 Thomas Broyer /t=C9=94.ma.b=CA=81wa.je/ --00000000000018428905cce5b717 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Sep 26, 2021 at 10:24 AM Neil= Madden <neil.madden@forger= ock.com> wrote:
Right, cookie prefixes is one app= roach - but still has a little way to go on browser share [1].=C2=A0
<= /div>

Fwiw, a big part of that "missin= g" browser share is Safari on iOS (14.25% of global share), and I just= tested on devices through BrowserStack on=C2=A0https://googlechrome.github.io/sam= ples/cookie-prefixes/ and it *does* support cookie prefixes (tested wit= h v14 and v13).
=C2=A0

= In my book (have I mentioned my book? :-)), I show a variant of the double-= submit cookie pattern in which the anti-CSRF token is a SHA-256 hash of the= session cookie [2], which prevents the cookie being overridden.

We should probably just defer to the= security considerations in rfc6265-bis [3], which already discusses some l= imitations of SameSite and recommends it be used as a defence-in-depth alon= gside traditional defences.=C2=A0

+1, just mentioning that there should be CSRF mitigations in place shoul= d be enough IMO.
Also maybe mention that securing the API is = then actually outside the scope of the BCP (whose role in this case is only= to recommend *not* using OAuth)

--
Thomas Broyer
/t=C9=94.ma.b=CA=81wa.je/
--00000000000018428905cce5b717-- From nobody Mon Sep 27 14:32:31 2021 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 8D6663A083C; Mon, 27 Sep 2021 14:32:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163277834938.13563.17822052879101335039@ietfa.amsl.com> Date: Mon, 27 Sep 2021 14:32:29 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-10-27 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, 27 Sep 2021 21:32:30 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-10-27 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: DPoP - Mike https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mcebff0f84a22f7685b909e11c6db6cc6 From nobody Mon Sep 27 14:33:00 2021 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 450EA3A0846; Mon, 27 Sep 2021 14:32:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163277836924.10730.15442028981360148215@ietfa.amsl.com> Date: Mon, 27 Sep 2021 14:32:49 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-10-06 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, 27 Sep 2021 21:32:57 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-10-06 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: HTTP Signature - Justin https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mcebff0f84a22f7685b909e11c6db6cc6 From nobody Mon Sep 27 14:33:16 2021 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 51DC23A0922; Mon, 27 Sep 2021 14:33:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163277838131.11216.7432587159429958821@ietfa.amsl.com> Date: Mon, 27 Sep 2021 14:33:01 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-10-13 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, 27 Sep 2021 21:33:09 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-10-13 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: OAuth 2.1 - Aaron https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mcebff0f84a22f7685b909e11c6db6cc6 From nobody Mon Sep 27 14:33:23 2021 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 68C6B3A0898; Mon, 27 Sep 2021 14:33:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.38.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163277839339.19858.8386600138817169376@ietfa.amsl.com> Date: Mon, 27 Sep 2021 14:33:13 -0700 Archived-At: Subject: [OAUTH-WG] Web Authorization Protocol (oauth) WG Virtual Meeting: 2021-10-20 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, 27 Sep 2021 21:33:20 -0000 The Web Authorization Protocol (oauth) WG will hold a virtual interim meeting on 2021-10-20 from 12:00 to 13:00 America/Toronto (16:00 to 17:00 UTC). Agenda: RAR - Torsten https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/ Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mcebff0f84a22f7685b909e11c6db6cc6 From nobody Mon Sep 27 15:15:21 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B47B3A0BB8 for ; Mon, 27 Sep 2021 15:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QDjbCInRPtCq for ; Mon, 27 Sep 2021 15:15:13 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3833A0BB3 for ; Mon, 27 Sep 2021 15:15:12 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id r23so29117688wra.6 for ; Mon, 27 Sep 2021 15:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5HR3z4gxoc9jGax4TWH+/C5usOSY/+ptQYf4uwF2UaQ=; b=fJxGJLjr4UL74iDZumDfg7yvW69alweNA3IWxBQsIdcOvoX5cf+sLjFnN31jA0+i8S dGPh0L2n9d6PFYkLdFcwRtmX9NA8kMLIaRkCVQXX+BkC+PEKCgdiR3uuMMAQFJE+DfQ3 BGTOd9nzgGe1FcKUJzHJqntR4s2h5f32fQwz4hoGdVfEDvNkrlYBBhiiJxEvjuhVRR2d wTSOAOzy7UUw4V2b4+QIGs73mghqKxVBxEkfhFu45JiFwPDmtLXLpMDfEcBNVW0aQj4D qRgXTc555HcT/NbgQlmhKUgstCth8ZIkBPafhdcHTkdaqiPqC9atRBNbJeFWHLc8RGVO oTDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5HR3z4gxoc9jGax4TWH+/C5usOSY/+ptQYf4uwF2UaQ=; b=J6iardd1v2j5RB8ikVgRCRYJIVnhHTrjU8NkP4hkmnFWU/SGvF+l3Ad7NnfR0ryRa6 O0oeqbHxlSky5PMeNo6fppokntqB2/+8kK4e0ltolFU3XN8gcCZpXAqsilKgfjuq9p+k 3ayu/HYocIJPw+gECTQTqkvR3wBe7AfvAyOgWCBCcuRPVU7XeUp/dx0pcNtMWvMq8xQL x2n3cPfKLccoLlASzbBIdIYr3pA/D/fOw76TApexCM6T4IksYxNRAx1vAU6MDhbxIG9e 1AwIdyEzJ79MQYRpDziQRz4r9o2j4+E0MxkCJpwa8mDyXCaMntbkEW2P5F0QWGc9gJtP KZ3Q== X-Gm-Message-State: AOAM5334JRVSgGsUiXXrk6PHJPEuvotpi6YzFj6Gdc34bwC2Im1zT6Zn BM8nWWyPZ0dVNVxgBFyZ0Zla/UrRuYqN2epT2OeyKPVGZaA= X-Google-Smtp-Source: ABdhPJwqTvZvogRPyDIIMjXjUxhEaxoCcuAsC2Fh59Ukrg+c2DKsnRQMmLng+lEmknriGfX6pOeQcbsfjv29y1rs2Fo= X-Received: by 2002:adf:fcc1:: with SMTP id f1mr2492158wrs.189.1632780910337; Mon, 27 Sep 2021 15:15:10 -0700 (PDT) MIME-Version: 1.0 References: <435715564.525941632780465704.JavaMail.nobody@rva2rmd101.webex.com> In-Reply-To: <435715564.525941632780465704.JavaMail.nobody@rva2rmd101.webex.com> From: Rifaat Shekh-Yusef Date: Mon, 27 Sep 2021 18:14:59 -0400 Message-ID: To: oauth Content-Type: multipart/mixed; boundary="0000000000002850c905cd016e99" Archived-At: Subject: [OAUTH-WG] Fwd: Webex meeting changed: OAuth WG Interims - October 2021 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2021 22:15:19 -0000 --0000000000002850c905cd016e99 Content-Type: multipart/alternative; boundary="0000000000002850c705cd016e97" --0000000000002850c705cd016e97 Content-Type: text/plain; charset="UTF-8" Attached are the details of the Webex that we will be using during the coming interim meetings. As you might have seen already, we have the following interim meetings: *1. HTTP Signature - Justin - October 6* *2. OAuth 2.1 - Aaron - October 13* *3. RAR - Torsten - October 20* *4. DPoP - Mike - October 27* Regards, Rifaat & Hannes ---------- Forwarded message --------- From: Web Authorization Protocol Working Group Date: Mon, Sep 27, 2021 at 6:07 PM Subject: Webex meeting changed: OAuth WG Interims - October 2021 To: You changed the Webex meeting information. When it's time, start your Webex meeting here. Occurs every Wednesday effective Wednesday, October 6, 2021 until Wednesday, October 27, 2021 from 12:00 PM to 1:00 PM, (UTC-04:00) Eastern Time (US & Canada) 12:00 PM | (UTC-04:00) Eastern Time (US & Canada) | 1 hr Start meeting *More ways to join:* *Join from the meeting link* https://ietf.webex.com/ietf/j.php?MTID=mcebff0f84a22f7685b909e11c6db6cc6 *Join by meeting number* Meeting number (access code): 2433 141 4281 Meeting password: NQu43NnicM2 *Tap to join from a mobile device (attendees only)* +1-650-479-3208,,24331414281## <%2B1-650-479-3208,,*01*24331414281%23%23*01*> Call-in toll number (US/Canada) *Join by phone* 1-650-479-3208 Call-in toll number (US/Canada) Global call-in numbers *Join from a video system or application* Dial 24331414281@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. If you are a host, click here to view host information. Need help? Go to https://help.webex.com --0000000000002850c705cd016e97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Attached are the details of the Webex that we will be usin= g during the coming interim meetings.
As you might have=C2=A0seen alrea= dy, we have the following interim meetings:

1. HTTP Signature - Justin - October 6

2. OAuth 2.1 - Aaron = - October 13

3. R= AR - Torsten - October 20

4. DPoP - Mike - October 27


<= /b>

Regards,
=C2=A0Rifaat & Hannes
<= div>

---------- Forwarded message ---------
From: Web Authorization Protocol Working Group <messenger@webex.com>
Date: Mon, Sep 27, 2021 at 6:= 07 PM
Subject: Webex meeting changed: OAuth WG Interims - October 2021To: <oauth= -chairs@ietf.org>


=C2=A0
=09

You changed the Webex meeting information.

=C2=A0

When it's time, start your Webex meeting here.

=C2=A0
=C2=A0
Occurs every Wednesday effective Wednesday, October 6, = 2021 until Wednesday, October 27, 2021 from 12:00 PM to 1:00 PM, (UTC-04:00= ) Eastern Time (US & Canada)
12:00 PM=C2=A0=C2=A0|=C2=A0=C2=A0(UTC-04:00) Eastern Time (US &= ; Canada)=C2=A0=C2=A0|=C2=A0=C2=A01 hr
=C2=A0
Start meeting
=
= =C2=A0
More ways to join:
=C2=A0
Join from the meeting link
https://ietf.webex.com/ietf/j.php?MTID=3Dmcebff0f84a22f7685b909e11c6db6cc6=
=C2= =A0
Join by meeting number
Meeting number (access code): 2433 141 4281
Meeting password: NQu43NnicM2
=C2= =A0
=20 =
Tap to join from a mobile device = (attendees only)
+1-650-= 479-3208,,24331414281## Call-in toll number (US/Canada)
=C2=A0
Join by phone
1-650-479-3208=C2=A0Call-in toll number (US/Canada)
Global call-in numbers
=C2= =A0
Dial 24331414281@ietf.webe= x.com
Join = from a video system or application
You can also dial 173.243.2.= 68 and enter your meeting number.
=20
=C2= =A0
If you are a host, click here to view host information.
=C2=A0
Need help? Go to https://help.we= bex.com
=C2=A0
--0000000000002850c705cd016e97-- --0000000000002850c905cd016e99 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 Content-ID: <17c294ff230475802341> X-Attachment-Id: 17c294ff230475802341 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNCkxBU1QtTU9ESUZJRUQ6MjAyMDEwMTFUMDE1 OTExWg0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25laW5mby1vdXRsb29rL0FtZXJpY2EvTmV3 X1lvcmsNClgtTElDLUxPQ0FUSU9OOkFtZXJpY2EvTmV3X1lvcmsNCkJFR0lOOkRBWUxJR0hUDQpU Wk5BTUU6RURUDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0MDANCkRUU1RBUlQ6 MTk3MDAzMDhUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTM7QllEQVk9MlNVDQpF TkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk5BTUU6RVNUDQpUWk9GRlNFVEZST006LTA0 MDANClRaT0ZGU0VUVE86LTA1MDANCkRUU1RBUlQ6MTk3MDExMDFUMDIwMDAwDQpSUlVMRTpGUkVR PVlFQVJMWTtCWU1PTlRIPTExO0JZREFZPTFTVQ0KRU5EOlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05F DQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMTA5MjdUMjIwNzQ1Wg0KQVRURU5ERUU7Q049Ildl YiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmcgR3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQ QU5UO1JTVlA9RkFMU0U6TUFJTFRPOm9hdXRoLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NO PSJDaXNjbyBXZWJleCI6TUFJTFRPOm1lc3NlbmdlckB3ZWJleC5jb20NCkRUU1RBUlQ7VFpJRD1B bWVyaWNhL05ld19Zb3JrOjIwMjExMDA2VDEyMDAwMA0KRFRFTkQ7VFpJRD1BbWVyaWNhL05ld19Z b3JrOjIwMjExMDA2VDEzMDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bWNlYmZmMGY4NGEyMmY3Njg1YjkwOWUxMWM2ZGI2Y2M2DQpUUkFOU1A6T1BB UVVFDQpTRVFVRU5DRToxNjMyNzgwNDY1DQpVSUQ6YjYyN2U3YjktMzJlMi00YTEzLWI0MDktZTc5 MTMxODcxOTJiDQpERVNDUklQVElPTjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1jZWJmZjBmODRhMjJmNzY4NWI5MDllMTFj NmRiNmNjNlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMjQzMyAxNDEgNDI4MVxuXG5c bk1lZXRpbmcgcGFzc3dvcmQ6IE5RdTQzTm5pY00yXG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEg TU9CSUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDI0MzMxNDE0 MjgxIyMgdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMjQzMzE0MTQyODElMjMlMjMqMDEqIENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cbkdsb2JhbCBjYWxsLWlu IG51bWJlcnNcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01U SUQ9bTZiNTU5ODQ2ZDgwOWMxNDkwY2IyNmRmOThlNmZjZTc1XG5cblxuSk9JTiBGUk9NIEEgVklE RU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDoyNDMzMTQxNDI4MUBpZXRmLndlYmV4 LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRp bmcgbnVtYmVyLlxuXG5cblxuSWYgeW91IGFyZSBhIGhvc3QsIGNsaWNrIGhlcmUgdG8gdmlldyBo b3N0IGluZm9ybWF0aW9uOlxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTEzMzBmMjlmZjQ2NmZmYmY5ZWY4MmFkZDJkZTg5NGRlXG5cblxuXG5DYW4ndCBqb2luIHRoZSBt ZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBz ZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhl IHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBs ZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlv ciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRpbmcuXG4NClgt QUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbnRhYmxl IHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwli b3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRk IHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxu LnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwlt YXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7 XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0 bGUge1xuCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRo OiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290 ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0 YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZG RkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAl OyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90 ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4 OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9y ZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6 IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFs aWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPi0tPlxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJ CQkJPEZPTlQgU0laRT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3Mg dGltZSwgam9pbiB0aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJ CQk8L3RyPlxuCQk8L3RhYmxlPlxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4J CQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5 bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojMDA4 MjNCOyBib3JkZXI6MHB4IHNvbGlkICMwMDgyM0I7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdp ZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tY2ViZmYwZjg0YTIyZjc2ODViOTA5ZTExYzZkYjZjYzYi IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4J CQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG4JCTx0YWJsZT5cbgkJCTx0ciBzdHlsZT0i bGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+XG4JCQk8dHI+XG4JCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5Nb3JlIHdheXMgdG8gam9pbjo8L0ZPTlQ+XG4JCQkJPC90ZD5cbiAg ICAgICAgCTwvdHI+XG4gICAgICAgICAgICA8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6IDEwcHg7Ij4mbmJzcDs8L3RkPjwvdHI+XG4gICAgICAgIAk8dHI+ XG4JCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5Kb2luIGZyb20gdGhlIG1lZXRpbmcgbGluazwvRk9OVD5cbgkJCQk8L3RkPlxuICAgICAg ICAJPC90cj5cbiAgICAgICAgCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxhIGhyZWY9J2h0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW1jZWJmZjBmODRhMjJmNzY4NWI5MDllMTFjNmRiNmNjNicgc3R5 bGU9J2NvbG9yOiMwMDVFN0Q7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFy aWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1jZWJmZjBmODRhMjJmNzY4NWI5MDllMTFjNmRiNmNjNjwv YT48L0ZPTlQ+XG4JCQkJPC90ZD5cbiAgICAgICAgCTwvdHI+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBtZWV0aW5nIG51bWJlcjwvRk9OVD5cbgkJCQk8L3Rk PlxuICAgICAgICAJPC90cj5cbgkJCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogMjQzMyAxNDEgNDI4MTwvRk9OVD5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5c bgkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5OUXU0M05uaWNNMjwvRk9OVD48L3RkPjwvdHI+PC90 YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxC Uj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFS SUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlRhcCB0byBq b2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L0ZPTlQ+ICZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSd0 ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoyNDMzMTQxNDI4MSUyMyUyMyowMSonIHN0eWxlPSdj b2xvcjojMDA1RTdEOyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtm b250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4rMS02NTAtNDc5LTMyMDgsLDI0MzMx NDE0MjgxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7 IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjEtNjUwLTQ3OS0zMjA4 IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSJodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW02YjU1OTg0NmQ4MDljMTQ5 MGNiMjZkZjk4ZTZmY2U3NSIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZTox NHB4O2NvbG9yOiMwMDVFN0QiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8L2E+PC9GT05UPiZuYnNw OyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48 dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT5cblxuPEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9uPC9GT05UPjxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+ IDxhIGhyZWY9InNpcDoyNDMzMTQxNDI4MUBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiMwMDVFN0QiIEZBQ0U9ImFyaWFsIj4yNDMzMTQxNDI4MUBpZXRmLndlYmV4LmNvbTwv Rk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0 aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZuYnNwOyA8QlI+XG5cblxuXG4J PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuCTx0YWJsZT48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1z aXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPklmIHlvdSBhcmUgYSBob3N0LCA8YSBocmVm PSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMTMzMGYyOWZmNDY2ZmZi ZjllZjgyYWRkMmRlODk0ZGUiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDA1 RTdEIj5jbGljayBoZXJlPC9hPiB0byB2aWV3IGhvc3QgaW5mb3JtYXRpb24uPC90ZD48L3RyPjwv dGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiAyMHB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cHM6Ly9oZWxwLndl YmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwMDVFN0Q7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0 cHM6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAgICAgICAg ICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJ PC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpPQXV0aCBXRyBJ bnRlcmltcyAtIE9jdG9iZXIgMjAyMQ0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpG UkVRPVdFRUtMWTtXS1NUPVNVO0NPVU5UPTQ7SU5URVJWQUw9MTtCWURBWT1XRQ0KQkVHSU46VkFM QVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXIN CkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --0000000000002850c905cd016e99 Content-Type: application/ics; name="Webex_Meeting.ics" Content-Disposition: attachment; filename="Webex_Meeting.ics" Content-Transfer-Encoding: base64 Content-ID: <17c294ff230c1ce7aee2> X-Attachment-Id: 17c294ff230c1ce7aee2 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNCkxBU1QtTU9ESUZJRUQ6MjAyMDEwMTFUMDE1 OTExWg0KVFpVUkw6aHR0cDovL3R6dXJsLm9yZy96b25laW5mby1vdXRsb29rL0FtZXJpY2EvTmV3 X1lvcmsNClgtTElDLUxPQ0FUSU9OOkFtZXJpY2EvTmV3X1lvcmsNCkJFR0lOOkRBWUxJR0hUDQpU Wk5BTUU6RURUDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VUVE86LTA0MDANCkRUU1RBUlQ6 MTk3MDAzMDhUMDIwMDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtCWU1PTlRIPTM7QllEQVk9MlNVDQpF TkQ6REFZTElHSFQNCkJFR0lOOlNUQU5EQVJEDQpUWk5BTUU6RVNUDQpUWk9GRlNFVEZST006LTA0 MDANClRaT0ZGU0VUVE86LTA1MDANCkRUU1RBUlQ6MTk3MDExMDFUMDIwMDAwDQpSUlVMRTpGUkVR PVlFQVJMWTtCWU1PTlRIPTExO0JZREFZPTFTVQ0KRU5EOlNUQU5EQVJEDQpFTkQ6VlRJTUVaT05F DQpCRUdJTjpWRVZFTlQNCkRUU1RBTVA6MjAyMTA5MjdUMjIwNzQ1Wg0KQVRURU5ERUU7Q049Ildl YiBBdXRob3JpemF0aW9uIFByb3RvY29sIFdvcmtpbmcgR3JvdXAiO1JPTEU9UkVRLVBBUlRJQ0lQ QU5UO1JTVlA9RkFMU0U6TUFJTFRPOm9hdXRoLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NO PSJDaXNjbyBXZWJleCI6TUFJTFRPOm1lc3NlbmdlckB3ZWJleC5jb20NCkRUU1RBUlQ7VFpJRD1B bWVyaWNhL05ld19Zb3JrOjIwMjExMDA2VDEyMDAwMA0KRFRFTkQ7VFpJRD1BbWVyaWNhL05ld19Z b3JrOjIwMjExMDA2VDEzMDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bWNlYmZmMGY4NGEyMmY3Njg1YjkwOWUxMWM2ZGI2Y2M2DQpUUkFOU1A6T1BB UVVFDQpTRVFVRU5DRToxNjMyNzgwNDY1DQpVSUQ6YjYyN2U3YjktMzJlMi00YTEzLWI0MDktZTc5 MTMxODcxOTJiDQpERVNDUklQVElPTjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1jZWJmZjBmODRhMjJmNzY4NWI5MDllMTFj NmRiNmNjNlxuTWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMjQzMyAxNDEgNDI4MVxuXG5c bk1lZXRpbmcgcGFzc3dvcmQ6IE5RdTQzTm5pY00yXG5cblxuXG5UQVAgVE8gSk9JTiBGUk9NIEEg TU9CSUxFIERFVklDRSAoQVRURU5ERUVTIE9OTFkpXG4rMS02NTAtNDc5LTMyMDgsLDI0MzMxNDE0 MjgxIyMgdGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMjQzMzE0MTQyODElMjMlMjMqMDEqIENh bGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxuXG5KT0lOIEJZIFBIT05FXG4xLTY1MC00 NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpXG5cbkdsb2JhbCBjYWxsLWlu IG51bWJlcnNcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9nbG9iYWxjYWxsaW4ucGhwP01U SUQ9bTZiNTU5ODQ2ZDgwOWMxNDkwY2IyNmRmOThlNmZjZTc1XG5cblxuSk9JTiBGUk9NIEEgVklE RU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9OXG5EaWFsIHNpcDoyNDMzMTQxNDI4MUBpZXRmLndlYmV4 LmNvbVxuWW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRp bmcgbnVtYmVyLlxuXG5cblxuSWYgeW91IGFyZSBhIGhvc3QsIGNsaWNrIGhlcmUgdG8gdmlldyBo b3N0IGluZm9ybWF0aW9uOlxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTEzMzBmMjlmZjQ2NmZmYmY5ZWY4MmFkZDJkZTg5NGRlXG5cblxuXG5DYW4ndCBqb2luIHRoZSBt ZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBz ZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhl IHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBs ZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlv ciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRpbmcuXG4NClgt QUxULURFU0M7Rk1UVFlQRT10ZXh0L2h0bWw6PHN0eWxlIHR5cGU9InRleHQvY3NzIj5cbnRhYmxl IHtcbglib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyB3aWR0aCA9MTAwJTsJYm9yZGVyOiAwOwli b3JkZXItc3BhY2luZzogMDt9XG5cbnRyIHtcbglsaW5lLWhlaWdodDogMThweDt9XG5cbmEsIHRk IHtcbglmb250LXNpemU6IDE0cHg7CWZvbnQtZmFtaWx5OiBBcmlhbDsJY29sb3I6ICMzMzM7CXdv cmQtd3JhcDogYnJlYWstd29yZDsJd29yZC1icmVhazogbm9ybWFsOwlwYWRkaW5nOiAwO31cblxu LnRpdGxlIHtcbglmb250LXNpemU6IDI4cHg7fVxuXG4uaW1hZ2Uge1xuCXdpZHRoOiBhdXRvOwlt YXgtd2lkdGg6IGF1dG87fVxuXG4uZm9vdGVyIHtcbgl3aWR0aDogNjA0cHg7fVxuXG4ubWFpbiB7 XG5cbn1AbWVkaWEgc2NyZWVuIGFuZCAobWF4LWRldmljZS13aWR0aDogODAwcHgpIHtcbgkudGl0 bGUge1xuCQlmb250LXNpemU6IDIycHggIWltcG9ydGFudDsJfVxuCS5pbWFnZSB7XG4JCXdpZHRo OiBhdXRvICFpbXBvcnRhbnQ7CQltYXgtd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJfVxuCS5mb290 ZXIge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0 YW50XG4JfVxuCS5tYWluIHtcbgkJd2lkdGg6IDEwMCUgIWltcG9ydGFudDsJCW1heC13aWR0aDog NjA0cHggIWltcG9ydGFudFxuCX1cbn1cbjwvc3R5bGU+XG5cbjx0YWJsZSBiZ2NvbG9yPSIjRkZG RkZGIiBzdHlsZT0icGFkZGluZzogMDsgbWFyZ2luOiAwOyBib3JkZXI6IDA7IHdpZHRoOiAxMDAl OyIgYWxpZ249ImxlZnQiPlxuCTx0ciBzdHlsZT0iaGVpZ2h0OiAyOHB4Ij48dGQ+Jm5ic3A7PC90 ZD48L3RyPlxuCTx0cj5cbgkJPHRkIGFsaWduPSJsZWZ0IiBzdHlsZT0icGFkZGluZzogMCAyMHB4 OyBtYXJnaW46IDAiPlxuCQkJPCEtLTx0YWJsZSBiZ2NvbG9yPSIjRkZGRkZGIiBzdHlsZT0iYm9y ZGVyOiAwcHg7IHdpZHRoOiAxMDAlOyBwYWRkaW5nLWxlZnQ6IDUwcHg7IHBhZGRpbmctcmlnaHQ6 IDUwcHg7IiBhbGlnbj0ibGVmdCIgY2xhc3M9Im1haW4iPlxuCQkJCTx0cj5cbgkJCQkJPHRkIGFs aWduPSJjZW50ZXIiIHZhbGlnbj0idG9wIiA+Jm5ic3A7CQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4J CQk8L3RhYmxlPi0tPlxuXG5cblxuCQkJPHRhYmxlPlxuCQkJCTx0cj5cbgkJCQkJPHRkPlxuCQkJ CQkJPEZPTlQgU0laRT0iNCIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5XaGVuIGl0J3Mg dGltZSwgam9pbiB0aGUgV2ViZXggbWVldGluZyBoZXJlLjwvRk9OVD5cbgkJCQkJPC90ZD5cbgkJ CQk8L3RyPlxuCQk8L3RhYmxlPlxuICAgICAgICA8dGFibGU+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZCBzdHlsZT0id2lkdGg6YXV0byFpbXBvcnRhbnQ7ICI+XG4J CQkJCTx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgc3R5 bGU9IndpZHRoOmF1dG87d2lkdGg6YXV0byFpbXBvcnRhbnQ7YmFja2dyb3VuZC1jb2xvcjojMDA4 MjNCOyBib3JkZXI6MHB4IHNvbGlkICMwMDgyM0I7IGJvcmRlci1yYWRpdXM6MjVweDsgbWluLXdp ZHRoOjE2MHB4IWltcG9ydGFudDsiPlxuCQkJCQkJPHRyPlxuCQkJCQkJCTx0ZCBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0icGFkZGluZzoxMHB4IDM2cHg7Ij48YSBocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tY2ViZmYwZjg0YTIyZjc2ODViOTA5ZTExYzZkYjZjYzYi IHN0eWxlPSJjb2xvcjojRkZGRkZGOyBmb250LXNpemU6MjBweDsgdGV4dC1kZWNvcmF0aW9uOm5v bmU7Ij5Kb2luIG1lZXRpbmc8L2E+PC90ZD5cbgkJCQkJCTwvdHI+XG4JCQkJCTwvdGFibGU+XG4J CQkJPC90ZD5cbgkJCTwvdHI+XG4JCTwvdGFibGU+XG4JCTx0YWJsZT5cbgkJCTx0ciBzdHlsZT0i bGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwv dHI+XG4JCQk8dHI+XG4JCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2 NjYiIEZBQ0U9ImFyaWFsIj5Nb3JlIHdheXMgdG8gam9pbjo8L0ZPTlQ+XG4JCQkJPC90ZD5cbiAg ICAgICAgCTwvdHI+XG4gICAgICAgICAgICA8dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAxMHB4OyI+ PHRkIHN0eWxlPSJoZWlnaHQ6IDEwcHg7Ij4mbmJzcDs8L3RkPjwvdHI+XG4gICAgICAgIAk8dHI+ XG4JCQkJPHRkPlxuCQkJCQkJPEZPTlQgU0laRT0iMyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5Kb2luIGZyb20gdGhlIG1lZXRpbmcgbGluazwvRk9OVD5cbgkJCQk8L3RkPlxuICAgICAg ICAJPC90cj5cbiAgICAgICAgCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxhIGhyZWY9J2h0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9qLnBocD9NVElEPW1jZWJmZjBmODRhMjJmNzY4NWI5MDllMTFjNmRiNmNjNicgc3R5 bGU9J2NvbG9yOiMwMDVFN0Q7ICB0ZXh0LWRlY29yYXRpb246bm9uZTsgZm9udC1mYW1pbHk6IEFy aWFsO2ZvbnQtc2l6ZTogMTRweDtsaW5lLWhlaWdodDogMjRweDsnPmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW1jZWJmZjBmODRhMjJmNzY4NWI5MDllMTFjNmRiNmNjNjwv YT48L0ZPTlQ+XG4JCQkJPC90ZD5cbiAgICAgICAgCTwvdHI+XG4gICAgICAgIAk8dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48 L3RyPlxuCQkJPHRyPlxuCQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBtZWV0aW5nIG51bWJlcjwvRk9OVD5cbgkJCQk8L3Rk PlxuICAgICAgICAJPC90cj5cbgkJCTx0cj5cbgkJCQk8dGQ+XG4JCQkJCTxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2Rl KTogMjQzMyAxNDEgNDI4MTwvRk9OVD5cbgkJCQk8L3RkPlxuCQkJPC90cj5cbgkJPC90YWJsZT5c bgkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFy aWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIyIiAgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5OUXU0M05uaWNNMjwvRk9OVD48L3RkPjwvdHI+PC90 YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxC Uj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFS SUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPlRhcCB0byBq b2luIGZyb20gYSBtb2JpbGUgZGV2aWNlIChhdHRlbmRlZXMgb25seSk8L0ZPTlQ+ICZuYnNwOyA8 QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSd0 ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSoyNDMzMTQxNDI4MSUyMyUyMyowMSonIHN0eWxlPSdj b2xvcjojMDA1RTdEOyAgdGV4dC1kZWNvcmF0aW9uOm5vbmU7IGZvbnQtZmFtaWx5OiBBcmlhbDtm b250LXNpemU6IDE0cHg7bGluZS1oZWlnaHQ6IDI0cHg7Jz4rMS02NTAtNDc5LTMyMDgsLDI0MzMx NDE0MjgxIyM8L2E+IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7 IDxCUj48QlI+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9S PSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4gJm5ic3A7IDxCUj48 Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjEtNjUwLTQ3OS0zMjA4 IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48YSBocmVmPSJodHRwczovL2ll dGYud2ViZXguY29tL2lldGYvZ2xvYmFsY2FsbGluLnBocD9NVElEPW02YjU1OTg0NmQ4MDljMTQ5 MGNiMjZkZjk4ZTZmY2U3NSIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2ZvbnQtc2l6ZTox NHB4O2NvbG9yOiMwMDVFN0QiPkdsb2JhbCBjYWxsLWluIG51bWJlcnM8L2E+PC9GT05UPiZuYnNw OyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48 dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT5cblxuPEZPTlQg U0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNF PSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8gc3lzdGVtIG9yIGFwcGxpY2F0aW9uPC9GT05UPjxC Uj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+ IDxhIGhyZWY9InNpcDoyNDMzMTQxNDI4MUBpZXRmLndlYmV4LmNvbSI+PEZPTlQgU0laRT0iMiIg Q09MT1I9IiMwMDVFN0QiIEZBQ0U9ImFyaWFsIj4yNDMzMTQxNDI4MUBpZXRmLndlYmV4LmNvbTwv Rk9OVD48L2E+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0 aW5nIG51bWJlci48L0ZPTlQ+ICZuYnNwOyA8QlI+PC9GT05UPiZuYnNwOyA8QlI+XG5cblxuXG4J PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIw cHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPlxuCTx0YWJsZT48dHIgc3R5bGU9Im1hcmdpbjow cHgiPjx0ZCBzdHlsZT0iY29sb3I6ICMzMzMzMzM7IGZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1z aXplOiAxNHB4OyBsaW5lLWhlaWdodDogMjRweDsiPklmIHlvdSBhcmUgYSBob3N0LCA8YSBocmVm PSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMTMzMGYyOWZmNDY2ZmZi ZjllZjgyYWRkMmRlODk0ZGUiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDA1 RTdEIj5jbGljayBoZXJlPC9hPiB0byB2aWV3IGhvc3QgaW5mb3JtYXRpb24uPC90ZD48L3RyPjwv dGFibGU+XG5cbgkJCTx0YWJsZSBzdHlsZT0id2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCIgY2xh c3M9Im1haW4iPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiAyMHB4Ij48dGQ+ Jm5ic3A7PC90ZD48L3RyPlxuCQkJCTx0cj5cbgkJCQkJPHRkIHN0eWxlPSJoZWlnaHQ6IDI0cHg7 IGNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTpBcmlhbDsgZm9udC1zaXplOiAxNHB4OyBsaW5l LWhlaWdodDogMjRweDsiPk5lZWQgaGVscD8gR28gdG8gPGEgaHJlZj0iaHR0cHM6Ly9oZWxwLndl YmV4LmNvbSIgc3R5bGU9ImNvbG9yOiMwMDVFN0Q7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+aHR0 cHM6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJCQkJPC90ZD5cbgkJCQk8L3RyPlxuICAgICAgICAg ICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJ PC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxuPC90YWJsZT5cbg0KU1VNTUFSWTpPQXV0aCBXRyBJ bnRlcmltcyAtIE9jdG9iZXIgMjAyMQ0KUFJJT1JJVFk6NQ0KQ0xBU1M6UFVCTElDDQpSUlVMRTpG UkVRPVdFRUtMWTtXS1NUPVNVO0NPVU5UPTQ7SU5URVJWQUw9MTtCWURBWT1XRQ0KQkVHSU46VkFM QVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJUFRJT046UmVtaW5kZXIN CkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --0000000000002850c905cd016e99-- From nobody Tue Sep 28 18:54:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843DA3A1A3B for ; Tue, 28 Sep 2021 18:54: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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 ESym8XF6qCN6 for ; Tue, 28 Sep 2021 18:54:23 -0700 (PDT) Received: from mo-csw.securemx.jp (mo-csw1515.securemx.jp [210.130.202.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5553A1A3A for ; Tue, 28 Sep 2021 18:54:22 -0700 (PDT) Received: by mo-csw.securemx.jp (mx-mo-csw1515) id 18T1sKNR024867; Wed, 29 Sep 2021 10:54:20 +0900 X-Iguazu-Qid: 34trdvrI7t0hCezh2C X-Iguazu-QSIG: v=2; s=0; t=1632880459; q=34trdvrI7t0hCezh2C; m=QueMIXqTXC9x4kdfrg4mDsDCDfMPLIhat4Nhpio7giQ= Received: from imx2-a.toshiba.co.jp (imx2-a.toshiba.co.jp [106.186.93.35]) by relay.securemx.jp (mx-mr1512) id 18T1sJAm030452 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 29 Sep 2021 10:54:19 +0900 Received: from enc01.toshiba.co.jp (enc01.toshiba.co.jp [106.186.93.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by imx2-a.toshiba.co.jp (Postfix) with ESMTPS id 8551C1000A5 for ; Wed, 29 Sep 2021 10:54:19 +0900 (JST) Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.toshiba.co.jp with ESMTP id 18T1sJTT029086 for ; Wed, 29 Sep 2021 10:54:19 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ClpGl4FzsWhOphfSSmGmN4G4kR4m6hyfPkXKmHWfKidTeX8ez9QGm1JNEK66WdsNu5gRXsPwat5EU3D3uRD+CNDYMcbUbCEVWJpggE48zhoXx5zFmcePzfzK5KBPGcolCwLGGHj+S6r5ZsiEV6smxLEztm8P4rueLm9YK7jqe/TgNA4QNuET+5/mxXXaR8yGiZf4rJTCMqBg9AXNhTTJmkPMAQDXH1hq1/WDaOJJh3hM+ogpc1ee4WgHGkVcDdhNR4KINSZT4wp4CSF5p66aOaB+vvod3aCVttvKYcUP7brNyy9xyzOSJNNLasaXptWXXisdizwXCA9ZATfYis4kVg== 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; bh=UhQkpkCVWBcuNovOmzmucx9EtlQXhUbOPon59XieDXw=; b=nC1laxiQNJzMZwh+RbsDA8jcS0F3xxGe5rIDB7Zkw1zQrjfj+2/wraMj89v0fN/mwM17taU2PbTuVYlAJuMDXToKKfabuEW3pRmbEo9G666f4+l8U6QbAjrCThzmgJxZ7cROTVIcDINchj5OqdG7+nyIUSmUo47LWl9VRYYs6Elak5HyT5foontds333dEBn1QBpypgfhZKiEYlVWsBUMhtQVGsUE7u2YWPpaDCOcGCFQH7V/MspkZUajkirwm3iMJ3ZJN9VtzVfZBeiSPwFUSdt+InCCN9jZxmMkKGQhmITejNz69ybp644JcOs3K4GmAaFiamI+n8SRODQIQ/q+w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none From: To: Thread-Topic: self-issued access tokens Thread-Index: Ade01Nk+d5eF4L5tTXCgjU67TgIDjw== Date: Wed, 29 Sep 2021 01:54:15 +0000 X-TSB-HOP: ON Message-ID: Accept-Language: ja-JP, en-US Content-Language: ja-JP authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=toshiba.co.jp; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b783175-cbbc-4af0-f0ea-08d982ec0ae4 x-ms-traffictypediagnostic: TYYPR01MB6794: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0L3cJC1zPkZqdm0Nzim+5jXIXNaGMsJJz4081Hu2rpjwUDOfiN8aipr6Lz0uVgXalp7FKYRwr/sCg1yYvNlYyb5pWFQFXkeX7yCtS20PioSyEa0H4eJYHhhS5NmMKJgCbnxZOObwa0mRSniiW2gW/XU0jS2rsaU4gajvvVmq4ZUUG+Jhuf7BDOCFRv1jzKtCUmr0NLM2101nuan8QrLAEShAQmx4AKnukpsf9sacMdUy5vooEQwliX7FzJQCXjQpJARFPk5zaVIpx/WW8IGhSxHwO+WbyL4HSyIpq80I2xOiapep+5ecogKvkpe9mFAe9d89iGuPIm/NIDDBHmq1mnanuFjxaoNrepiw7yg/ySwf8PSD0aQRL0Ee/BvSlCZZjIq74hsEtOzVUeRT2WF/tJ5XUgDdszENIyNLT1hMdm9H2yFKWnFnuGqlO9GRmnzZHxQGUUkW8rWEQ+BuArC7BmNw2cDFPuHpI3C3pBdNxBQ7wtaeHsSWITFXNNBnBbCCTOJRl48Fg3q7kW3I7l91h7IDjMpNzmBGW67BGIuA48Lqa6M7C78KSr3jr0D0YEfSHj/5SgqQ+V/m8jdXpeFofvVo6rugTUJS1km5dCCFKcHmxerKhOfPl7bh9kdwq1eDVV/AgMHne/MwOvzVRxqTpqrXVDmrgAg7d+AfXsFR0AcqpSuPIRSq99bGBBCt1dx+s+7mG/4uBdAwVDYONizBAt1bLmuIkKHd0mUAo5Z66bmBF/aJW9CNFBeD1lFicv9+1D8xR74tIPxj0fJO2sFnjGvk9x1bYMuDfZM8v3RqjVc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYCPR01MB5678.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66476007)(66446008)(33656002)(3480700007)(122000001)(5660300002)(2906002)(6916009)(52536014)(7696005)(64756008)(83380400001)(86362001)(76116006)(26005)(66946007)(66556008)(9686003)(508600001)(38100700002)(55016002)(38070700005)(8676002)(71200400001)(6506007)(966005)(186003)(316002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?YWFEVEFkVE9MNTkyRS94bGwvNU11bExua0N4Q2VMcmhIRm1iUVdTQ25a?= =?iso-2022-jp?B?WklZZTladHlBSnpUbHNTQzFyMmNCalU2SVFvNnoyMHduRlVFZ04vV3pu?= =?iso-2022-jp?B?cmR1akRhUDh0Q0dpNFk2cEtxQlI2NUdJdzBPYW5lWGx1YjVheVF1cHlw?= =?iso-2022-jp?B?Vzd2Y1gzZEJyNDhsSGZ1Zis2a2hJbGxUQis3RXhMS3A2SWJyT0xTbzd2?= =?iso-2022-jp?B?MUQ0bExIM0xNeE9jQm1wQ2FBVDNTTm1uNjlLVnM1YjJ0MGFEWkx5TTZW?= =?iso-2022-jp?B?eXdJclpiZ1B5NktNRERmcHVYQXNXVk4vTGM4TmtwYU9LbGYzNWFpTnpp?= =?iso-2022-jp?B?T20zeEwwYW9Ud0x4QUcrQjZSbTJBRC9xKzJ5RFk2TXB6ODJPT28zRnBS?= =?iso-2022-jp?B?WkpHQTVZQ2VQY3ZRWE94MnNoenBHb29ocDd5TDByZ1VDdThRTTVXQnNB?= =?iso-2022-jp?B?N1VmYVRhUlRzZno3aUNBeDlDZCs2N2ZoWnBlN3pnK0N4L0xWaUIyNDRE?= =?iso-2022-jp?B?T1FrdlJqejJJVTR2QmlRNXV1Y1JtMSt5b1RxcVpYQ1g5eTFNeGpUUEV6?= =?iso-2022-jp?B?L1pGMVIwZWNTZ3RlUmxjbHRENWthcTBNeEtwakJtNk5vWFFpZSt3RmNm?= =?iso-2022-jp?B?MUNmUUx3Qkh5WFVETkMwRlByWlpZY2lOTU5qQzFiNk04dVZET2paeXM1?= =?iso-2022-jp?B?Q2hUakdqVlVvRTRpdmxOWHFEU3ZkNy90MmdYZzA0MDdMcE82MWVvVXJz?= =?iso-2022-jp?B?R2NwdDExMEV0eGJOclVodTU3UkxNbnd4TUp0cG1NU2d1UGI2TDduc0hr?= =?iso-2022-jp?B?OW1OUHBzZGpkaERIVFZ0MWprazc1MDBQUkVjUDkrKzB3V3BVL0ZlNTBu?= =?iso-2022-jp?B?QWJMRGo2TytVZml5dmdsYXBobmNKWjRtMUtQb0FZaXdjOThwbDJJUXlK?= =?iso-2022-jp?B?SWlaNFQ3R0JhUHVYZ01QYk9ZMEEvWGQvVjQramN0Q3ZXUDN2bG00Qjd0?= =?iso-2022-jp?B?RWJmcHUybWdzNjZVU1NtMmJKWVZUcExsSHAwd2tLRWlXM3ZzQ1pXc2FF?= =?iso-2022-jp?B?QVJqMEI2anRDNUtNOHU3TzdvNThjT0loMWVpOU5yNjREaDYxQUV6Mk5s?= =?iso-2022-jp?B?Y29pb0tDaUk2TzZWbVRDd2ZWcnJsOTFlZEcwTGIwQ1hIemxZRnI0emlF?= =?iso-2022-jp?B?TnFXMDZ4M0NQM1ZhK0hLcHd3d2RlVWZtTXc1NXFNZjJrM0x2ZjZEcm03?= =?iso-2022-jp?B?UWRBaWthMmthVC9HM2pya3BVd0tWcUUxQ0Vqd2hIOFBtY0VRUW90ZFFR?= =?iso-2022-jp?B?MGtZTDJqWXpidmZnd3hPM3JTZENudnQ4aXo4SkVBVE9uVzNPMHdYSm92?= =?iso-2022-jp?B?ZWZJcmkxeEJpb1lBb2djaEEyYUQyVTA0UXk2M3FqeWQ2NTEyRTJVMHVa?= =?iso-2022-jp?B?NGM3dm8rUm5NK2hSajh3amExUnNISVk1REFFeisyMFQyRWkzc1NaeW50?= =?iso-2022-jp?B?ODZ6bW1CQ242M1Q2cG5saUhjWjhKeHFabHR5YkI1azI3L1V0NXRCMThk?= =?iso-2022-jp?B?eDJPVXJWaDY0bTliMW9FbmdwWkNGVkdXNHRDL3pFMkJHRUpBK1hzQnBG?= =?iso-2022-jp?B?Yjlhc3phSXFXU2Vrd3RSK3h6MjB6d1RPOTZwVmpvRktadjExUnZ3MUhT?= =?iso-2022-jp?B?V3BBTEY3N0FIQ2I3Q25scjRuTm1WdFl5ekZIV3FTVlNYdnhQMzQ5YWJO?= =?iso-2022-jp?B?ZVUwT3hrMFNqSENaeC80cmlKTkt4cXFkVzBINXg4S3BHcEZ5WXJlcDRh?= =?iso-2022-jp?B?YWJqcnFiOUNlSHBvRm16cmZvc1BMOWswaTQ1Z1I0aGRIcU9kU1hVR2ky?= =?iso-2022-jp?B?SkVFaWZSem9kUHcvUmJLeDh6c3o0PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYCPR01MB5678.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b783175-cbbc-4af0-f0ea-08d982ec0ae4 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2021 01:54:15.5518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mdFX0qVoG6aGaJgN1PGvXcbefwRshwtcTwmVXhB33x5tn2/7eB0saKHf0BbFE5S+grgNz5AmJD3mL/Qv5H7P5a/hu4yotwu6bAfm88EIVg8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYPR01MB6794 MSSCP.TransferMailToMossAgent: 103 X-OriginatorOrg: toshiba.co.jp Archived-At: Subject: [OAUTH-WG] self-issued access 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, 29 Sep 2021 01:54:29 -0000 Hi OAuth folks, I have a question. Is there (or was there) any standardizing effort for "self-issued access tokens"? Self-issued access tokens are mentioned in a blog post by P. Siriwardena in= 2014 [*1]. It's an Access Token issued by the Client and sent to the Resource Se= rver. The token is basically a signed document (e.g. JWT) by the private key of t= he Client. The Resource Server verifies the token with the public key, which i= s provisioned in the RS in advance. I think self-issued access tokens are handy replacement for Client Credenti= als Grant flow in simple deployments, where it's not so necessary to separate A= S and RS. In fact, Google supports this type of authentication for some services [*2][*3]. I'm wondering if there are any other services supporting self-sig= ned access tokens. Any comments are welcome. [*1]: https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-acce= ss-tokens/ [*2]: https://developers.google.com/identity/protocols/oauth2/service-accou= nt#jwt-auth [*3]: https://google.aip.dev/auth/4111 ------------- Toshio Ito Research and Development Center Toshiba Corporation From nobody Tue Sep 28 23:06:34 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997E23A17EE for ; Tue, 28 Sep 2021 23:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 0UycwZA__Gwo for ; Tue, 28 Sep 2021 23:06:27 -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 48CBC3A17EB for ; Tue, 28 Sep 2021 23:06:27 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id g41so6188286lfv.1 for ; Tue, 28 Sep 2021 23:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A+4p7flPDUx2WVSufp3fyIFpq3E20S+EWEFrEbZfHY8=; b=Wf5gOMRp0wSqPK0EVmjIYi1LdTmQr/TNHggt+CnG0N6/3NQAbIUVqFvx9AUlVKKKcd 6scsYE2ye/B2euizpFmASJHTO13OOtOlAIt6oVlLzpOVgm0JwSQ01haCNrZn3erlj5sW BVEx8oBT3d6FyQc7RrOjXR9RTeiziq6Gm5LlPvqbrI1v/4cdlWZq5ZIfiXDr1K46cFYM pUjyvT9/OEvmuzeIzUoO90z3JwenJNHXH8WY9bk/902tgGwjAEGSGk5SS/JRRo5xMhgW zN/kzx+8TfOTr3h9K2LC2tAvoI3YuSz12gcZBZ0YUYIAk5llDjX3fpv+rm4tlJpPGdhs A/og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A+4p7flPDUx2WVSufp3fyIFpq3E20S+EWEFrEbZfHY8=; b=W0FgnMhEi/Mr86omz1b+SP4M5ErS+q8GmE9FZKYLnRV5IoIQ3E90snkdzTisvXsfJA Ql/5fiPRm2M1vc/xKmaW54Gp22oTdOXgNSDTNg+W+cTuLzopbGdBVP5dq7JjCaEAdDFg yUcojIM6cHsu/ypqkrpKqtJaJJSkWyROhABtIukjBgqCWFBW2QjCjGpe9DNE7y4EXOdk r0wbGeEMSsw9/QodI1F8fe8Z5vvT3uv4w4YprSuizqvqy97qJAKL9nVkGorF2MYa0KTX smABcctnPU7MZ8MRGjI1UkA20wFSVKSqtv4wIMF+y4Kv6mPqghdkrL3ooWDASQV1qQl4 UJoQ== X-Gm-Message-State: AOAM531JDJ2hFOLx1Pt0FoT8RuJWGAeiwDeKEbqIgzHfQJPLPN5ETleu 72Wxz1thEqEEfrwW5l0hy6+vtG+cFvtbwQJqu4Y= X-Google-Smtp-Source: ABdhPJxHuXxSG9evUzv+FfBwNMb+XRLI77rWqg7pSEbjwDugmFHtkkkHDr8q1WiUv3O8ZBQnDNQZNk6uHzFX0BeAGj0= X-Received: by 2002:a2e:98cd:: with SMTP id s13mr4109170ljj.79.1632895584432; Tue, 28 Sep 2021 23:06:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 28 Sep 2021 23:05:48 -0700 Message-ID: To: toshio9.ito@toshiba.co.jp Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000043f7d005cd1c21fb" Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 29 Sep 2021 06:06:33 -0000 --00000000000043f7d005cd1c21fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the client is sending a self-signed JWT to the RS, you essentially are just authenticating directly to the RS. Not really OAuth as the RS has not delegated authorization authority to the AS. If the client sends a self-signed JWT (a PAR) to the AS, and gets back an access token to present to the RS, you get centralized authorization decisions, a key feature of OAuth. =E1=90=A7 On Tue, Sep 28, 2021 at 6:55 PM wrote: > Hi OAuth folks, > > I have a question. Is there (or was there) any standardizing effort for > "self-issued access tokens"? > > Self-issued access tokens are mentioned in a blog post by P. Siriwardena > in 2014 > [*1]. It's an Access Token issued by the Client and sent to the Resource > Server. > The token is basically a signed document (e.g. JWT) by the private key of > the > Client. The Resource Server verifies the token with the public key, which > is > provisioned in the RS in advance. > > I think self-issued access tokens are handy replacement for Client > Credentials > Grant flow in simple deployments, where it's not so necessary to separate > AS and > RS. In fact, Google supports this type of authentication for some service= s > [*2][*3]. I'm wondering if there are any other services supporting > self-signed > access tokens. > > Any comments are welcome. > > [*1]: > https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-t= okens/ > [*2]: > https://developers.google.com/identity/protocols/oauth2/service-account#j= wt-auth > [*3]: https://google.aip.dev/auth/4111 > > ------------- > Toshio Ito > Research and Development Center > Toshiba Corporation > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000043f7d005cd1c21fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the client is sending a self-signed JWT to the RS,= you essentially are just authenticating directly to the RS. Not really OAu= th as the RS has not delegated authorization authority to the AS.=C2=A0

If the client sends a self-signed JWT (a PAR) to the = AS, and gets back an access token to present to the RS, you get centralized= authorization decisions, a key feature of OAuth.

3D""=E1=90=A7

On Tue, Sep 28, 2021 at 6:55 PM <toshio9.ito@toshiba.co.jp> wrote:
Hi OAuth folks,
I have a question. Is there (or was there) any standardizing effort for
"self-issued access tokens"?

Self-issued access tokens are mentioned in a blog post by P. Siriwardena in= 2014
[*1]. It's an Access Token issued by the Client and sent to the Resourc= e Server.
The token is basically a signed document (e.g. JWT) by the private key of t= he
Client. The Resource Server verifies the token with the public key, which i= s
provisioned in the RS in advance.

I think self-issued access tokens are handy replacement for Client Credenti= als
Grant flow in simple deployments, where it's not so necessary to separa= te AS and
RS. In fact, Google supports this type of authentication for some services<= br> [*2][*3]. I'm wondering if there are any other services supporting self= -signed
access tokens.

Any comments are welcome.

[*1]: https://wso2.co= m/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
[*2]: https://develo= pers.google.com/identity/protocols/oauth2/service-account#jwt-auth
[*3]: https://google.aip.dev/auth/4111

-------------
Toshio Ito
Research and Development Center
Toshiba Corporation



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000043f7d005cd1c21fb-- From nobody Tue Sep 28 23:13:29 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEC33A1852 for ; Tue, 28 Sep 2021 23:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 jopZkvu6zTn8 for ; Tue, 28 Sep 2021 23:13:23 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54E93A1851 for ; Tue, 28 Sep 2021 23:13:22 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id b82so2979154ybg.1 for ; Tue, 28 Sep 2021 23: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:from:date:message-id:subject:to :cc; bh=IIZE3IcHfRL45Pi+hEqmloqa86JywUiMJxu+kB69zOg=; b=dQX/iV2mqv73uFtoftT/hB+LUygDR41L7h/4MVeHLLiVSAPQTO5wPvTfI98CPuJ82+ +x/r/RFsKNKBjJbvVuw1xeVqMbnpWwGoAZxkRS0QkUNPWpOGkpTsL3zoyxxJ5cHWrrOP ozqy2bvgCvm2E7Dp80mEwEp0tVp1uAENAQuAlbYRpZtHx6Yofl/51Psfbm8T5WVRPAx4 cDlosei1KxsbJnJNsJ++hODSLKgosRr820/MlY5wD67RwmTqCaeP8ksL4EyrrTawS+zq AWxBdOpr2FDcdmGtR84dFAvye7mRqP1ftjvyaEt2DOKdTRNaicm51C/7Ydfsz3DoQAuf 0aiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IIZE3IcHfRL45Pi+hEqmloqa86JywUiMJxu+kB69zOg=; b=6IdUKKCJN7LduWIp/S9rdGSxF1g+2jYAM7tQns8XaocS9FeldcRJ4nBa27LeI05LO7 F2ZgbEaOab9uDSW1vnplb8K63HXLDFO4XuKkXBAcL8j+oFyM0LtgJaktJCSO+Soiurub avHdrThsufbGwSA8qxn6N0IPzbdP9DqmM0ywUDThh4iUlb+GV53CX5aPS5+sx5ZunBXC U4RwaB5kx1+JprVrSj4riwx4NDPgf2mlDKCjy7/z/QhkMrL9/xCdaWJ0s/zhbvutzpKR r6a5lOd5JzVdoAHeq+RhdO86wL6VtqogqfF3zp4PoGyrvqUcrTeGnzbYnzpM8RRUNCZs Naog== X-Gm-Message-State: AOAM531+GEJxXxNtb5bG3t0tig+JHg/e38BD1CccAwY42kCzBzTjkNYK /oflNGO8xrhZ+SBXHeT/ejkXRgRr0n4fP7o4q4wf6w== X-Google-Smtp-Source: ABdhPJwLJL7w0bO0yxxrLioPGhcbM6qB6Wv7T11o3xEbxON/CZFtxySO7nlx6iZdA/nZi6zHo4FXutNU+mrHva+GThg= X-Received: by 2002:a25:3891:: with SMTP id f139mr11970471yba.54.1632896001631; Tue, 28 Sep 2021 23:13:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vittorio Bertocci Date: Tue, 28 Sep 2021 23:13:10 -0700 Message-ID: To: toshio9.ito@toshiba.co.jp Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000022080105cd1c3aa9" Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 29 Sep 2021 06:13:28 -0000 --00000000000022080105cd1c3aa9 Content-Type: text/plain; charset="UTF-8" Hi Toshio, The scenario you describe is comparable to https://openid.net/specs/openid-connect-self-issued-v2-1_0.html, at least in terms of validation logic. Please note that most of the validation software in common use today expects to work with just a handful of keys, typically one provider and allowance for rotation, hence it might not be trivial to repurpose it to perform large table scans in scenarios where you have many clients and corresponding keys. Also, Prabath's blog makes a statement that, I believe, overstates what can be achieved with this approach: he says that this can be a replacement for TLS mutual authentication, but it isn't really the case as you are still dealing with a bearer token, which can be replayed after issuance hence offering less guarantees than mutual TLS. On Tue, Sep 28, 2021 at 6:54 PM wrote: > Hi OAuth folks, > > I have a question. Is there (or was there) any standardizing effort for > "self-issued access tokens"? > > Self-issued access tokens are mentioned in a blog post by P. Siriwardena > in 2014 > [*1]. It's an Access Token issued by the Client and sent to the Resource > Server. > The token is basically a signed document (e.g. JWT) by the private key of > the > Client. The Resource Server verifies the token with the public key, which > is > provisioned in the RS in advance. > > I think self-issued access tokens are handy replacement for Client > Credentials > Grant flow in simple deployments, where it's not so necessary to separate > AS and > RS. In fact, Google supports this type of authentication for some services > [*2][*3]. I'm wondering if there are any other services supporting > self-signed > access tokens. > > Any comments are welcome. > > [*1]: > https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/ > [*2]: > https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth > [*3]: https://google.aip.dev/auth/4111 > > ------------- > Toshio Ito > Research and Development Center > Toshiba Corporation > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000022080105cd1c3aa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Toshio,
The scenario you describe is comparable=C2= =A0to=C2=A0https://openid.net/specs/openid-connect-self-issued-v2-1_0.html= , at least in terms of validation logic. Please note that most of the v= alidation software in common use today expects to work with just a handful = of keys, typically one provider and allowance for rotation, hence it might = not be trivial to repurpose it to perform large table scans in scenarios wh= ere you have many clients and corresponding keys.
Also, Prabath&#= 39;s blog makes a statement that, I believe, overstates what can be achieve= d with this approach: he says that this can be a replacement for TLS mutual= authentication, but it isn't really the case as you are still dealing = with a bearer token, which=C2=A0can be replayed after issuance hence offeri= ng less guarantees than mutual TLS.


On Tue, Sep 28, 202= 1 at 6:54 PM <toshio9.ito@toshiba.co.jp> wrote:
Hi OAuth folks,

I have a question. Is there (or was there) any standardizing effort for
"self-issued access tokens"?

Self-issued access tokens are mentioned in a blog post by P. Siriwardena in= 2014
[*1]. It's an Access Token issued by the Client and sent to the Resourc= e Server.
The token is basically a signed document (e.g. JWT) by the private key of t= he
Client. The Resource Server verifies the token with the public key, which i= s
provisioned in the RS in advance.

I think self-issued access tokens are handy replacement for Client Credenti= als
Grant flow in simple deployments, where it's not so necessary to separa= te AS and
RS. In fact, Google supports this type of authentication for some services<= br> [*2][*3]. I'm wondering if there are any other services supporting self= -signed
access tokens.

Any comments are welcome.

[*1]: https://wso2.co= m/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
[*2]: https://develo= pers.google.com/identity/protocols/oauth2/service-account#jwt-auth
[*3]: https://google.aip.dev/auth/4111

-------------
Toshio Ito
Research and Development Center
Toshiba Corporation



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000022080105cd1c3aa9-- From nobody Wed Sep 29 08:27:16 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62843A1ADA for ; Wed, 29 Sep 2021 08:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 SgnkihBsgtJH for ; Wed, 29 Sep 2021 08:27:08 -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 D88D53A0CDB for ; Wed, 29 Sep 2021 08:27:07 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id j5so7526820lfg.8 for ; Wed, 29 Sep 2021 08:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oBnuP8o3FGrK8+K03U2BVgJY064UQhi8rk5D71RWPnM=; b=PGK6dYXJhXP6//IGXLRuoy5m/gXX0xC5KW5aG7nznrc5WkpkRGG/oUcBp+jnjY1wS+ suxYXKhvuU7hIZtew/VTv3jiQbYG06trhz3JItFpQBwqzWQ3+VtZ80wmZj4eRx6kuc/X u1ZhJshff6aBPVgrW1YT8x716+6X/NXNLY65LV94k7GYQaM/yiuGrlFa1vRESTKqx9e8 NTlCpvycUpiW8spGfaoild5eYcgesfnkisWDfVOWgOVw4AeW/SJEB9HxGowoKpVK8PEE k9qWxehdTsFvg6bhYc/5tFH90CIm6iTWUEO4Uli56aDQsMkullXgmgijYa6dKE9Oju25 Z05Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oBnuP8o3FGrK8+K03U2BVgJY064UQhi8rk5D71RWPnM=; b=k2yR6mhElkX6nqVf2VDoYT1bXPAa5SJ0XmlGykvZsJo5p3oO6SSXJBjoOfndk9dJh4 E/hOIcxawHr4piQMqV4DIoobBxMyOBFeDDHth6Z5WCdtbfbPmck4PVIQLCqiAl65XfdO dec41zhdtpFnplAa3vdjdJ8qKQz3D7P2yrtfbWMHBIr3x3XFt+YDPope9LeicCUod/Rd n1tpPvOFQZe0DWuxkeQhA8HsZDjfoD2LtE7KDVcOTZ+K+yKqUayNSOJoTAdLVaFJoLLQ PazAlNGmMbnO0weE13kyxSfad7FjFsALDf8faDm87FsaT6aj+JqwePdL3x4DNnrwnoL6 LDJQ== X-Gm-Message-State: AOAM530zeZh23mMnH4os+SlnwfQMV+r2bUA/Or5judDmPbj9TLCFzTJz XlRGd7MqCfCrgNAE8ZQNm3G9P9MSB7ybqJsR4lwNdHEnd+M= X-Google-Smtp-Source: ABdhPJzrncY9lUpRAnt99hxAR5OwVsLAx7s0yzByY7s69YHAFt/fiXSZPutC0X4eQM0G4AFNtTK7ReMNF27tmrPMEKs= X-Received: by 2002:a19:6a16:: with SMTP id u22mr294906lfu.444.1632929225903; Wed, 29 Sep 2021 08:27:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sascha Preibisch Date: Wed, 29 Sep 2021 08:26:54 -0700 Message-ID: To: Vittorio Bertocci Cc: toshio9.ito@toshiba.co.jp, IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000074121705cd23f686" Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 29 Sep 2021 15:27:14 -0000 --00000000000074121705cd23f686 Content-Type: text/plain; charset="UTF-8" Vittorio, I wrote an approach where a client would receive a grant by the authorization server but issues the token itself. The post can be found here: https://oauth.blog/oauthblog.jsp (fancy name: Serverless Token Issuance) I presented the idea at IIW right before I wrote the post. I believe that it would work nicely and would avoid the need for an authorization servers to manage access_token. Regards, Sascha On Tue, 28 Sept 2021 at 23:13, Vittorio Bertocci wrote: > Hi Toshio, > The scenario you describe is comparable to > https://openid.net/specs/openid-connect-self-issued-v2-1_0.html, at least > in terms of validation logic. Please note that most of the validation > software in common use today expects to work with just a handful of keys, > typically one provider and allowance for rotation, hence it might not be > trivial to repurpose it to perform large table scans in scenarios where you > have many clients and corresponding keys. > Also, Prabath's blog makes a statement that, I believe, overstates what > can be achieved with this approach: he says that this can be a replacement > for TLS mutual authentication, but it isn't really the case as you are > still dealing with a bearer token, which can be replayed after issuance > hence offering less guarantees than mutual TLS. > > > On Tue, Sep 28, 2021 at 6:54 PM wrote: > >> Hi OAuth folks, >> >> I have a question. Is there (or was there) any standardizing effort for >> "self-issued access tokens"? >> >> Self-issued access tokens are mentioned in a blog post by P. Siriwardena >> in 2014 >> [*1]. It's an Access Token issued by the Client and sent to the Resource >> Server. >> The token is basically a signed document (e.g. JWT) by the private key of >> the >> Client. The Resource Server verifies the token with the public key, which >> is >> provisioned in the RS in advance. >> >> I think self-issued access tokens are handy replacement for Client >> Credentials >> Grant flow in simple deployments, where it's not so necessary to separate >> AS and >> RS. In fact, Google supports this type of authentication for some services >> [*2][*3]. I'm wondering if there are any other services supporting >> self-signed >> access tokens. >> >> Any comments are welcome. >> >> [*1]: >> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/ >> [*2]: >> https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth >> [*3]: https://google.aip.dev/auth/4111 >> >> ------------- >> Toshio Ito >> Research and Development Center >> Toshiba Corporation >> >> >> >> _______________________________________________ >> 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 > --00000000000074121705cd23f686 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Vittorio,

I wrote an approach where a c= lient would receive a grant by the authorization server but issues the toke= n itself. The post can be found here:
https://oauth.blog/oauthblog.jsp (fancy name: Serverl= ess Token Issuance) I presented the idea at IIW right before I wrote the po= st.

I believe that it would work nicely and wo= uld avoid the need for an authorization servers to manage access_token.

Regards,
Sascha

<= br>
On Tue,= 28 Sept 2021 at 23:13, Vittorio Bertocci <Vittorio=3D40auth0.com@dmarc.ietf.org> wrote:
Hi Toshio,
The scenario you descr= ibe is comparable=C2=A0to=C2=A0https://openid.net/specs/= openid-connect-self-issued-v2-1_0.html, at least in terms of validation= logic. Please note that most of the validation software in common use toda= y expects to work with just a handful of keys, typically one provider and a= llowance for rotation, hence it might not be trivial to repurpose it to per= form large table scans in scenarios where you have many clients and corresp= onding keys.
Also, Prabath's blog makes a statement that, I b= elieve, overstates what can be achieved with this approach: he says that th= is can be a replacement for TLS mutual authentication, but it isn't rea= lly the case as you are still dealing with a bearer token, which=C2=A0can b= e replayed after issuance hence offering less guarantees than mutual TLS.


On Tue, Sep 28, 2021 at 6:54 PM <toshio9.ito@toshiba.co.jp>= ; wrote:
Hi OAuth folks,

I have a question. Is there (or was there) any standardizing effort for
"self-issued access tokens"?

Self-issued access tokens are mentioned in a blog post by P. Siriwardena in= 2014
[*1]. It's an Access Token issued by the Client and sent to the Resourc= e Server.
The token is basically a signed document (e.g. JWT) by the private key of t= he
Client. The Resource Server verifies the token with the public key, which i= s
provisioned in the RS in advance.

I think self-issued access tokens are handy replacement for Client Credenti= als
Grant flow in simple deployments, where it's not so necessary to separa= te AS and
RS. In fact, Google supports this type of authentication for some services<= br> [*2][*3]. I'm wondering if there are any other services supporting self= -signed
access tokens.

Any comments are welcome.

[*1]: https://wso2.co= m/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
[*2]: https://develo= pers.google.com/identity/protocols/oauth2/service-account#jwt-auth
[*3]: https://google.aip.dev/auth/4111

-------------
Toshio Ito
Research and Development Center
Toshiba Corporation



_______________________________________________
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
--00000000000074121705cd23f686-- From nobody Wed Sep 29 08:42:31 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5503A1B0E for ; Wed, 29 Sep 2021 08:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=danielfett.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_SYiCt-6o93 for ; Wed, 29 Sep 2021 08:42:23 -0700 (PDT) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994393A1B0A for ; Wed, 29 Sep 2021 08:42:22 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id 7567B150D3 for ; Wed, 29 Sep 2021 15:42:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1632930136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6hUyMeYhXh+20r501J2HGYkr5Zih4VAjty7ligEUiTc=; b=h1e/KLYr87T2jgheWDP5gUzssCmg8CBpht37nHSB/Cor1ciITskILFVOJzgz5S3gNyy4e3 z3F2D79NuZ9OYhTxXQtMcPWpkETlF5hNOTq6Y8tdbG5VGWBeZ6y8CUTdL4h8kND78oy0p8 5D6YxOuE7CPzYJh/P9xhXYY2DZMtXDI= To: oauth@ietf.org References: From: Daniel Fett Message-ID: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> Date: Wed, 29 Sep 2021 17:42:15 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------25A068A1E99B970C49786697" Content-Language: de-DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1632930136; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6hUyMeYhXh+20r501J2HGYkr5Zih4VAjty7ligEUiTc=; b=remWL5q50P9bXogCxfKF7PWCMxF70GprnhF2viNUzyirzC2mkiNSb/Wz3zDYuKSFunrdA3 dNeYcHtF4dkLqv2fzvHtUB8R5zg/BiQrhdjnIqghGUTr+q+FQkntfwDR/OB0tW922lYWjJ MncFEZaLbks8hBG89ZPxtZx1AWOV1WY= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1632930136; a=rsa-sha256; cv=none; b=IwZSt3yvMrxXXR6tUFJM3NmvYrUY3CEX5esnwMlZjMXo+BeZMqNs0CTSJIBLBAkUKYzNWr S9Qpza8kEqcUn0uZMjZ2yCIidGGU5x4JhGOiAGHy2AQSKfxMTKxBm8KI+1JJNbxHM+wPcW dQNbASDXa2VI6KmflWOTfuTJOsYFWjc= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: -- Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 29 Sep 2021 15:42:29 -0000 This is a multi-part message in MIME format. --------------25A068A1E99B970C49786697 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit That very much sounds like a static string as the access token plus DPoP. -Daniel Am 29.09.21 um 03:54 schrieb toshio9.ito@toshiba.co.jp: > Hi OAuth folks, > > I have a question. Is there (or was there) any standardizing effort for > "self-issued access tokens"? > > Self-issued access tokens are mentioned in a blog post by P. Siriwardena in 2014 > [*1]. It's an Access Token issued by the Client and sent to the Resource Server. > The token is basically a signed document (e.g. JWT) by the private key of the > Client. The Resource Server verifies the token with the public key, which is > provisioned in the RS in advance. > > I think self-issued access tokens are handy replacement for Client Credentials > Grant flow in simple deployments, where it's not so necessary to separate AS and > RS. In fact, Google supports this type of authentication for some services > [*2][*3]. I'm wondering if there are any other services supporting self-signed > access tokens. > > Any comments are welcome. > > [*1]: https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/ > [*2]: https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth > [*3]: https://google.aip.dev/auth/4111 > > ------------- > Toshio Ito > Research and Development Center > Toshiba Corporation > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de --------------25A068A1E99B970C49786697 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
That very much sounds like a static string as the access token plus DPoP.

-Daniel

Am 29.09.21 um 03:54 schrieb toshio9.ito@toshiba.co.jp:
Hi OAuth folks,

I have a question. Is there (or was there) any standardizing effort for
"self-issued access tokens"?

Self-issued access tokens are mentioned in a blog post by P. Siriwardena in 2014
[*1]. It's an Access Token issued by the Client and sent to the Resource Server.
The token is basically a signed document (e.g. JWT) by the private key of the
Client. The Resource Server verifies the token with the public key, which is
provisioned in the RS in advance.

I think self-issued access tokens are handy replacement for Client Credentials
Grant flow in simple deployments, where it's not so necessary to separate AS and
RS. In fact, Google supports this type of authentication for some services
[*2][*3]. I'm wondering if there are any other services supporting self-signed
access tokens.

Any comments are welcome.

[*1]: https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/
[*2]: https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth
[*3]: https://google.aip.dev/auth/4111

-------------
Toshio Ito
Research and Development Center
Toshiba Corporation



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



-- 
https://danielfett.de
--------------25A068A1E99B970C49786697-- From nobody Wed Sep 29 21:56:11 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55973A11FA for ; Wed, 29 Sep 2021 21:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 e0o3HX93q7_H for ; Wed, 29 Sep 2021 21:56:03 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC53A3A11F9 for ; Wed, 29 Sep 2021 21:56:03 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id x27so20134877lfu.5 for ; Wed, 29 Sep 2021 21:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uzTQ1Xh3JsmskPtaA+GEQPHEZpcz/YE3k+wRahOpt4A=; b=OIobvHcq1Wg+9SYzAsTNOx/eYmEhDGdVvCfpU898a2A5qmgFauIIQZrtmwY/k6eVCJ xZPgfWThiRdXl9NdJYx4PFTqcwu5Z3ZCvE0wY49DuYOsTI7QXrpUC9tfi+GMPCgUiwu0 G0GV4ytm2jiRPReeh15/Z6kcgwRqE9vjqoEGsJ6UtorNtNm5rjTmrOWL1UP+AAj0o5fm sASvycbB+4QlT2f3KYy7V25pFnNhYAxZxBcv6MILB0FQbVs/G2K+ER3WO2BNT1/+fNjq gyYXlxvguc+0CzJTYDLDOvjp9JLxKZuuEyW5kYEfI+4lU9Ra9A9ukEg1/vl0cEy0uSST iyyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uzTQ1Xh3JsmskPtaA+GEQPHEZpcz/YE3k+wRahOpt4A=; b=rmEpgy4VHVwjgqvX168MKRwaZv2bgDtlSnhBMrz1xvkDgZjE6KpQSpvE+srM0tVarg 8d/8oRRJH6DWXJtNJgCbr3nXuevenqAtPPL7fOegv9Whw4KR61k2fxLthpfgDU4Wnsj8 ZtqZF5iDnTD1wxMMj8cJKG8uZ42jckdQRQRJ/jZNZHFcK2YEf0LtMVRWsvXVHcAsAqrc /S1pyE3j3luynJG08jbVq7QC1F9qGM91JkpcsD+Ko1wZYY1/rwlk5FUiOdrsRxXX7Vgl xM85ryP+QgIHdddOL1fpPB0q0qwhiivOSDTQa3K0n5Fb57x+HJwZ1+AfEe6jvMu3PYjm UuRw== X-Gm-Message-State: AOAM530qDOguzHBRjGdk0gkxW72+Fy02iSee5Z6gxZvoPBdtvcfBWqct sJuMCN/doN91liKB+/u1FlTlFZhjHXAj7supKzc= X-Google-Smtp-Source: ABdhPJzxEd0ZjMtjxCxjGfXsXLg6DEjT11QZ0njAE93krmKYPi+JpcL/VFykEzS5LxRoKYNvLJCYQmL5TelK9ZGmOs0= X-Received: by 2002:a05:6512:39d6:: with SMTP id k22mr3652643lfu.258.1632977761071; Wed, 29 Sep 2021 21:56:01 -0700 (PDT) MIME-Version: 1.0 References: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> In-Reply-To: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> From: Sascha Preibisch Date: Wed, 29 Sep 2021 21:55:50 -0700 Message-ID: To: Daniel Fett Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="00000000000060764605cd2f437f" Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 30 Sep 2021 04:56:09 -0000 --00000000000060764605cd2f437f Content-Type: text/plain; charset="UTF-8" Yeah, Daniel, I remember we spoke about it. I do think my version is slightly different as there is no access_token issued by the server. Regards, Sascha On Wed, 29 Sept 2021 at 08:42, Daniel Fett wrote: > That very much sounds like a static string as the access token plus DPoP. > > -Daniel > > Am 29.09.21 um 03:54 schrieb toshio9.ito@toshiba.co.jp: > > Hi OAuth folks, > > I have a question. Is there (or was there) any standardizing effort for > "self-issued access tokens"? > > Self-issued access tokens are mentioned in a blog post by P. Siriwardena in 2014 > [*1]. It's an Access Token issued by the Client and sent to the Resource Server. > The token is basically a signed document (e.g. JWT) by the private key of the > Client. The Resource Server verifies the token with the public key, which is > provisioned in the RS in advance. > > I think self-issued access tokens are handy replacement for Client Credentials > Grant flow in simple deployments, where it's not so necessary to separate AS and > RS. In fact, Google supports this type of authentication for some services > [*2][*3]. I'm wondering if there are any other services supporting self-signed > access tokens. > > Any comments are welcome. > > [*1]: https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/ > [*2]: https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth > [*3]: https://google.aip.dev/auth/4111 > > ------------- > Toshio Ito > Research and Development Center > Toshiba Corporation > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- https://danielfett.de > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00000000000060764605cd2f437f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, Daniel,

I remember we spoke about= it. I do think my version is slightly different as there is no access_toke= n issued by the server.

Regards,
Sascha<= /div>

On Wed, 29 Sept 2021 at 08:42, Daniel Fett <fett@danielfett.de> wrote:
=20 =20 =20
That very much sounds like a static string as the access token plus DPoP.

-Daniel

Am 29.09.21 um 03:54 schrieb toshio= 9.ito@toshiba.co.jp:
Hi OAuth folks,

I have a question. Is there (or was there) any standardizing effort for
"self-issued access tokens"?

Self-issued access tokens are mentioned in a blog post by P. Siriwardena in=
 2014
[*1]. It's an Access Token issued by the Client and sent to the Resourc=
e Server.
The token is basically a signed document (e.g. JWT) by the private key of t=
he
Client. The Resource Server verifies the token with the public key, which i=
s
provisioned in the RS in advance.

I think self-issued access tokens are handy replacement for Client Credenti=
als
Grant flow in simple deployments, where it's not so necessary to separa=
te AS and
RS. In fact, Google supports this type of authentication for some services
[*2][*3]. I'm wondering if there are any other services supporting self=
-signed
access tokens.

Any comments are welcome.

[*1]: https://wso2.com/library/blog-post=
/2014/10/blog-post-self-issued-access-tokens/
[*2]: https://developers.google.com/ide=
ntity/protocols/oauth2/service-account#jwt-auth
[*3]: https:=
//google.aip.dev/auth/4111

-------------
Toshio Ito
Research and Development Center
Toshiba Corporation



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



--=20
https://danielfett.de
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--00000000000060764605cd2f437f-- From nobody Wed Sep 29 23:47:56 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED963A15EB for ; Wed, 29 Sep 2021 23:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=aueb.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmnqEL9w7zIF for ; Wed, 29 Sep 2021 23:47:49 -0700 (PDT) Received: from blade-b3-vm-relay.servers.aueb.gr (blade-b3-vm-relay.servers.aueb.gr [195.251.255.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9998A3A15E6 for ; Wed, 29 Sep 2021 23:47:46 -0700 (PDT) Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [195.251.255.217]) by blade-b3-vm-relay.servers.aueb.gr (Postfix) with ESMTP id 198F3E50; Thu, 30 Sep 2021 09:47:44 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aueb.gr; s=201901; t=1632984464; bh=k9F7BFIohYnfwyeygAtIi/V8Ne85bMU1x0NstW/k1gI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=pWxCEjkL9yFKfZCxtf+ABQS9++DLm3s6o6DiVqy8252sf/Vo9wwYTd1FkbWbfunwW HdWForj1BkuPzPwDIejPePGWcoHjtREwxPUaJqmM4tY4KsEgn/F0hMbpANQyBpKGak x7mt2b+iDdhhTqiFjWBAfBJKJqnbEYi6aJOM3M2zs4PM1bXf3pw9lwuRC0lS5FN3sL ktf4jiajS3Z5sstL7xpeWbcRbJEDXfvSdhOTBuk14ZaOtkkIa91cPjzlemAVEShCpQ DZGNoRjNPNVfm54QsRlDfYw80rYDaI184MUiFr3NFMnVrNlGQ+slCmltwwENici4en rOCxb1GIeU4/A== Received: from smtpclient.apple (ppp-2-86-52-197.home.otenet.gr [2.86.52.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fotiou) by blade-a1-vm-smtp.servers.aueb.gr (Postfix) with ESMTPSA id 984504E7; Thu, 30 Sep 2021 09:47:43 +0300 (EEST) From: Nikos Fotiou Message-Id: <09C675DC-1DC8-4860-A4DD-CE70B1FD5577@aueb.gr> Content-Type: multipart/signed; boundary="Apple-Mail=_70F5995D-1260-4C37-96EE-FE9CD4B9043C"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 30 Sep 2021 09:47:42 +0300 In-Reply-To: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> Cc: oauth@ietf.org To: Daniel Fett References: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 30 Sep 2021 06:47:55 -0000 --Apple-Mail=_70F5995D-1260-4C37-96EE-FE9CD4B9043C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, this is exactly what we are doing in [1] to manage Verifiable = Credentials using OAuth2.0. The AS issues a verifiable credential that = stays (for long time) in the client. The client uses DPoP to prove = ownership of the credential. We just started a new project funded by = essif [2] that will further develop this idea and provide = implementations. Best, Nikos [1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access = control for multi-tenant systems using Oauth 2.0 and Verifiable = Credentials," Proc. 30th International Conference on Computer = Communications and Networks (ICCCN), Athens, Greece, July 2021 = (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf)= [2]https://essif-lab.eu -- Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr > On 29 Sep 2021, at 6:42 PM, Daniel Fett wrote: >=20 > That very much sounds like a static string as the access token plus = DPoP. >=20 > -Daniel >=20 > Am 29.09.21 um 03:54 schrieb toshio9.ito@toshiba.co.jp: >> Hi OAuth folks, >>=20 >> I have a question. Is there (or was there) any standardizing effort = for >> "self-issued access tokens"? >>=20 >> Self-issued access tokens are mentioned in a blog post by P. = Siriwardena in 2014 >> [*1]. It's an Access Token issued by the Client and sent to the = Resource Server. >> The token is basically a signed document (e.g. JWT) by the private = key of the >> Client. The Resource Server verifies the token with the public key, = which is >> provisioned in the RS in advance. >>=20 >> I think self-issued access tokens are handy replacement for Client = Credentials >> Grant flow in simple deployments, where it's not so necessary to = separate AS and >> RS. In fact, Google supports this type of authentication for some = services >> [*2][*3]. I'm wondering if there are any other services supporting = self-signed >> access tokens. >>=20 >> Any comments are welcome. >>=20 >> [*1]:=20 >> = https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-to= kens/ >>=20 >> [*2]:=20 >> = https://developers.google.com/identity/protocols/oauth2/service-account#jw= t-auth >>=20 >> [*3]:=20 >> https://google.aip.dev/auth/4111 >>=20 >>=20 >> ------------- >> Toshio Ito >> Research and Development Center >> Toshiba Corporation >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 >=20 > https://danielfett.de > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_70F5995D-1260-4C37-96EE-FE9CD4B9043C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDgkw ggbQMIIEuKADAgECAhBAB3aGT+I5a2zJV9kPcbUZMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQG EwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9u cyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWlj cyBhbmQgQnVzaW5lc3MgQ0EgUjIwHhcNMTkxMjEyMTQxNzU4WhcNMjExMjExMTQxNzU4WjCCAQkx CzAJBgNVBAYTAkdSMQ8wDQYDVQQHDAZBdGhlbnMxNDAyBgNVBAoMK0F0aGVucyBVbml2ZXJzaXR5 IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtl eSBjcmVhdGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMQ8wDQYDVQQEDAZGT1RJT1kxETAP BgNVBCoMCE5JS09MQU9TMRMwEQYDVQQFEwozODY2OTQxMjIxMRgwFgYDVQQDDA9OSUtPTEFPUyBG T1RJT1kxHTAbBgkqhkiG9w0BCQEWDmZvdGlvdUBhdWViLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAgLLzGBqZBB4A0EYdBSjLSUYjNMZYSS14Z4+Esf6iK7wrSw8pOfjLBMqtJOyw azPxWgmmvhk6PaCLhZYgwPqdGQk3z+m3Hm2ao9fnFghTIBhXyypOJVCEVNblcY1r6+HZZLZZ/Z5N nMLuNKK+uWQ7dRR/GZDOFGcnOtcmMx9GKrgSrawVOsghzBRg5wLbvCaCNJsJ90mRYsyUjkg9OglG 2dzZ7Bi02BzozUwP69dFaKG7ml12C9FwQiaBURg3dDbgl7AuGY1AZcqBAPwKNni0Jkpl5XL2Jzjb zQj73EbTFMrsgG1PbGw/uZgQyCqAVHS1HiIJhyMTn7cttd5CobkMMwIDAQABo4IBqTCCAaUwHwYD VR0jBBgwFoAUd2BZxxknkkBQvIKZbY8+SdAQ9CowbQYIKwYBBQUHAQEEYTBfMDoGCCsGAQUFBzAC hi5odHRwOi8vcmVwby5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhQXVlYkNBUjIuY3J0MCEGCCsGAQUF BzABhhVodHRwOi8vb2NzcC5oYXJpY2EuZ3IwGQYDVR0RBBIwEIEOZm90aW91QGF1ZWIuZ3IwWAYD VR0gBFEwTzAIBgYEAI96AQEwQwYNKwYBBAGBzxEBAQICATAyMDAGCCsGAQUFBwIBFiRodHRwczov L3JlcG8uaGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUF BwMEBgorBgEEAYI3CgMMMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmx2MS5oYXJpY2EuZ3Iv SGFyaWNhQXVlYkNBUjIvY3JsdjEuZGVyLmNybDAdBgNVHQ4EFgQUcMJMYLF3+xjl9x4Fc4V2qRdA oVIwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAo/QEb7ED5Z7e3qdVPfIdKRpnL Q+JH3V7w4CKouEZkSjH2m+y0WOtMoF4cPCNrMH90n/IH9QuGcyYALRQTXAKsgF5s5TIeHc8fpFAe sjoVjTHTijK94b4ekh81jU/o8sRhsfWjPzAjzhSogWuh9yYox7fx0pvnux9lGE2+mVhE0xJqzP4N 6zGmVsYYOg6YfOtjYK46lvT5WOKkdK9lD9S3vmws0BPOCirvIqc9/fzKngZMTcsXMEZp91z40SuU xn48P370TKgvzIkmnDVB/iOobkdErAgp5j2o6s/Bt2m91VwLW3xOIV4F9y8BGOxsRqvRkv7wMKmh TjkAT+MVF7uw1S+vmeTeL+pdFUBAKJRizEqjCL6D7ZwpKszeMhi6Sx31ooOPpTOWtPh/fLfRRJBY NFcrYgMlBr0WWe1nIYajWskliR+5HNyNY8/zQApm9SGqr4VjaYdEwnU+NVLiZ2pikWyrg5B8Qyqc JCNdZRezjOPqM6DN+t52HMSnqHFxsy6cqOfqOSAsitZT2LkBWVDj3TxkENnw04hPUS4ip48jMB0s zuajEMmKqs5/uGY9EyQ3bHlDDWQxu/DULZJOcsZPX67mcOTLfXOXFnyW/gOGbvCgitlimm7xrDHm VWvB4AE7XPK7ogjGmG1qEq7vnYOcgj93DGizi+QkmVMCJwpGYjCCBzEwggYZoAMCAQICCBjdh64f S7Z7MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNh ZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMT N0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEw HhcNMTUwNzI4MDcxMDQ4WhcNMjMwNzI2MDcxMDQ4WjCBjzELMAkGA1UEBhMCR1IxRDBCBgNVBAoT O0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9y aXR5MTowOAYDVQQDEzFBdGhlbnMgVW5pdmVyc2l0eSBvZiBFY29ub21pY3MgYW5kIEJ1c2luZXNz IENBIFIyMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjTO6hsbRRbmkpEjRUM1K7/Mn 2XgBgh/Tp6AbDXt5rS/oFBc/GJ5bCJFc7P1d1LHMSM1VT0advzlwE2xdnR0X9ThYKIm67gOAs1RU HxLqSYcrg2qkGdm1LadSwfn8KTDAxXynmVHhduU5jOTWS/LbX18EkZQ0tWiTEHxN+Uj7RFGzPrrE C6C3x+W/jZ9uZEfjLOxC0FHkYGndlHWh2SnoJyKvcWXE1F3DEdsGhm7gK/wxRG70U1ryihV3upd4 3YNdxEzBBEP2RIR8UDPLt4UpdfmmTk9uVJR6waYYtpnF10PSpuMRXNqV2dtlXCz8OEuoWFSlJbUF 7VmwiZIDg5P7INZ9bRWercaBquvOdDk0hBcuUfadx7TfPQHRhhUAP9UGvGcJsX7gP/3R0eUMGC6Q H+Ly5LKdfHpubVABNQnXcKXgVQtjJWGObSGsnz/X3PmhF+MYlQRtrT7852Paf0xnQ1klXaLpd04j RK/EoVrJs9jZWggPatQsX9aWuXR7xWGqOR3kT7aetAwk3FgT896eUj5V1C5eJZy9b21SJm5ux2Wt mrcpCtDcYSafDaJ/0toGUPnZZnDMyyKYbuQvNu7AVYcT5uFTu84JKTqjl8jrXb4PITFN7rjKPOb0 geJm+RtTDe9Shan4d0vty9xWUDvMV5utJPIkreaRdGDbbNJQkP0CAwEAAaOCAocwggKDMA8GA1Ud EwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR3YFnHGSeSQFC8gpltjz5J0BD0 KjBGBgNVHR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEuaGFyaWNhLmdyL0hhcmljYVJvb3RDQTIw MTEvY3JsdjEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9E2FKI54IpCnl2BMEI+5BJTBuBggrBgEF BQcBAQRiMGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLmhhcmljYS5ncjA7BggrBgEFBQcwAoYv aHR0cDovL3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhUm9vdENBMjAxMS5jcnQwggE3BgNVHSAE ggEuMIIBKjCCASYGBFUdIAAwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5nci9k b2N1bWVudHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVtaWMgYW5k IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoGJVGhp cyBjZXJ0aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91ciBDUFMuIFRoaXMg Q2VydGlmaWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBl ZHVjYXRpb25hbCBwdXJwb3Nlcy4wLQYDVR0eBCYwJKAiMAmCB2F1ZWIuZ3IwCYEHYXVlYi5ncjAK gQguYXVlYi5ncjANBgkqhkiG9w0BAQsFAAOCAQEAhSXJoQDbTRBYH549pfk9+3CjT+HnAcFajp60 aV8UYR63DZflolPCDagaRxADLd3SpbOuGlRGNw+MgYpAp/d6i5BfVpjMVIhp5E7zr6TDJgVIwt2U xuLejfowumCNkRJD+RrdUcLKHzcPOfSD40MRHprehXT1bvyuka26ogF6U0T2uEDoOIaObV/RS9wg Gx9y63/QIc/tsZNQ3pzcAbTecnax6ITfSvnnfeMol6IcS+rKxPwKjPPFQq93qT8w61qe+zEx54vR wJXi241edkTmBTJddM5Cdhxxy98xYX+eYNnf5x96vVDQ1qc2wcecMHADZBrfVV/tx0Ev6hTlYBhO mzGCA68wggOrAgEBMIGkMIGPMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVt aWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0 aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MgQ0EgUjICEEAHdoZP4jlr bMlX2Q9xtRkwDQYJYIZIAWUDBAIBBQCgggHbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTIxMDkzMDA2NDc0MlowLwYJKoZIhvcNAQkEMSIEIG461dsd2yoDfhaNwqPp oeqhEoTIwYp9ssVWlpaRnkuCMIG1BgkrBgEEAYI3EAQxgacwgaQwgY8xCzAJBgNVBAYTAkdSMUQw QgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQu IEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBC dXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZD3G1GTCBtwYLKoZIhvcNAQkQAgsxgaeggaQwgY8x CzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5z dGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2Yg RWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZD3G1GTANBgkqhkiG9w0B AQsFAASCAQBgBbAvaK3h72yFtZbraBZMnuJS/LzyVXAK7bTOWKWKHYV2q0gaySoDho4q6QEKYVUy aty845j1MfjrWHYwLU5MtNLkXGd6GowKVHprBD05taiuFszHQAx4B6COTvpsnGOLVy+MwWO17jnX mm5qV7ZVrGFwAWFg51zQi6TjkKfGhDcZg1uQ8ytLc23FmuH+snHWT1gKnMs/T2JEZKaJvssB/lfZ T/nacXyeMvLkGtjbUtdhFV6/9Idixlipc4yqonTlHUOVKkLPkmXCGaeRV07BwN43pDpo+UU2R+tl gIv6dniVPZGjYop8ohWWxrZHD5kHxsarAOe9dwZchecRabD4AAAAAAAA --Apple-Mail=_70F5995D-1260-4C37-96EE-FE9CD4B9043C-- From nobody Thu Sep 30 10:44:36 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECE53A0E13 for ; Thu, 30 Sep 2021 10:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=alkaline-solutions.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SggZkpDlD3gG for ; Thu, 30 Sep 2021 10:44:29 -0700 (PDT) Received: from caesium6.alkaline.solutions (caesium6.alkaline.solutions [157.230.133.164]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CE23A0783 for ; Thu, 30 Sep 2021 10:44:29 -0700 (PDT) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by caesium6.alkaline.solutions (Postfix) with ESMTPA id 45543206E83; Thu, 30 Sep 2021 17:44:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alkaline-solutions.com; s=dkim; t=1633023868; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=NoymUePfjK3ylNBvg39gr5ncOrgSLwy5Zi92wj6Kz1Q=; b=J7bnTvqgZBkYQwuanCbVDyS1PR2pYEUwuDptqrbk+DAprJTEUX0DvhWh9/ApWkVWSDFPtv 3At1uY6iRWG401Hf71l5SihCeZIIUdnpVDVcIXava5Aw4JKWwo1XnWbm6Xr4cIeVaPly7a nqM7RiVWWkYRPCBpdpn7Tg1JYrob1dk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 From: David Waite In-Reply-To: <09C675DC-1DC8-4860-A4DD-CE70B1FD5577@aueb.gr> Date: Thu, 30 Sep 2021 11:44:25 -0600 Cc: Daniel Fett , oauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> <09C675DC-1DC8-4860-A4DD-CE70B1FD5577@aueb.gr> To: Nikos Fotiou Authentication-Results: caesium6.alkaline.solutions; auth=pass smtp.mailfrom=david@alkaline-solutions.com X-Spamd-Bar: / Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 30 Sep 2021 17:44:35 -0000 Are you using DPoP at issuance of the credential and embedding the = public key as the means to verify the subject? Are you going so far as = using DPoP in lieu of Verifiable Presentation wrappers? -DW > On Sep 30, 2021, at 12:47 AM, Nikos Fotiou wrote: >=20 > FYI, this is exactly what we are doing in [1] to manage Verifiable = Credentials using OAuth2.0. The AS issues a verifiable credential that = stays (for long time) in the client. The client uses DPoP to prove = ownership of the credential. We just started a new project funded by = essif [2] that will further develop this idea and provide = implementations. >=20 > Best, > Nikos >=20 > [1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access = control for multi-tenant systems using Oauth 2.0 and Verifiable = Credentials," Proc. 30th International Conference on Computer = Communications and Networks (ICCCN), Athens, Greece, July 2021 = (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c.pdf)= > [2]https://essif-lab.eu > -- > Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou > Researcher - Mobile Multimedia Laboratory > Athens University of Economics and Business > https://mm.aueb.gr From nobody Thu Sep 30 14:40:40 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A283A14D3 for ; Thu, 30 Sep 2021 14:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=aueb.gr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTej1R81OH6z for ; Thu, 30 Sep 2021 14:40:33 -0700 (PDT) Received: from blade-b3-vm-relay.servers.aueb.gr (blade-b3-vm-relay.servers.aueb.gr [195.251.255.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6143D3A14D2 for ; Thu, 30 Sep 2021 14:40:32 -0700 (PDT) Received: from blade-a1-vm-smtp.servers.aueb.gr (blade-a1-vm-smtp.servers.aueb.gr [195.251.255.217]) by blade-b3-vm-relay.servers.aueb.gr (Postfix) with ESMTP id 5176FEEB; Fri, 1 Oct 2021 00:40:29 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aueb.gr; s=201901; t=1633038029; bh=h6uWORVL4ans0d4cCpWEayfXeEpeTVqnnxBL4sxU2q8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=Y7n2B5MGYijrBwFGxSeqzZkfiQvUW2n6dLO0Y2FlTcmWrTGv6yB4mtnxhTH61U74v sc9TIkbql3qmDvNMDO4UNSmBlroHPpwa5MN9y/J77zeRJu9t/2IOiNEyyOo1yCqDLy B4or78aMFNnqkRyzMKGW61FUs2obkF81S+2IeRL8pRSychX47ykRhLPy0nDguI5U0f 23fnQcvTNJUhtSMkEI3OG+2zrLRUaktqtbKi4D2I73URhHYdi0dWBCr+VOtqP2MLiC 3SC4Nc5/6eLq5+01eKXy7u9CvYMnP4gzNse4+Aw474dEcq1Nh6w4ZQCDcOcUE9os0y vkmbdsoPO3myA== Received: from Desktop (ppp-2-86-52-197.home.otenet.gr [2.86.52.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: fotiou@aueb.gr) by blade-a1-vm-smtp.servers.aueb.gr (Postfix) with ESMTPSA id 60F1362C; Fri, 1 Oct 2021 00:40:28 +0300 (EEST) From: "Nikos Fotiou" To: "'David Waite'" Cc: "'Daniel Fett'" , References: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> <09C675DC-1DC8-4860-A4DD-CE70B1FD5577@aueb.gr> In-Reply-To: Date: Fri, 1 Oct 2021 00:40:14 +0300 Message-ID: <03ee01d7b643$c175dcf0$446196d0$@aueb.gr> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJHvEqUsGilElT6hyA9kc7dS79kMgIK+/1wAiXbS/UCLWtg2KqqGE+A Content-Language: el MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_03E9_01D7B65C.E5D69210" Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 30 Sep 2021 21:40:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03E9_01D7B65C.E5D69210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Are you using DPoP at issuance of the credential and embedding the public key as the means to verify the subject? Exactly. We are using "client credentials" as grant type. The credential used as grant is client's public key and we are using DPoP to prove possession. Then the public key is embedded in the VC (which is encoded as a JWT). > Are you going so far as using DPoP in lieu of Verifiable Presentation wrappers? Yes. Since our VCs are encoded in JWT, they are included in the Authorization header of HTTP requests and we are using DPoP to prove possession. So we do not use Verifiable Presentations at all. Best, Nikos > On Sep 30, 2021, at 12:47 AM, Nikos Fotiou wrote: > > FYI, this is exactly what we are doing in [1] to manage Verifiable Credentials using OAuth2.0. The AS issues a verifiable credential that stays (for long time) in the client. The client uses DPoP to prove ownership of the credential. We just started a new project funded by essif [2] that will further develop this idea and provide implementations. > > Best, > Nikos > > [1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access > control for multi-tenant systems using Oauth 2.0 and Verifiable > Credentials," Proc. 30th International Conference on Computer > Communications and Networks (ICCCN), Athens, Greece, July 2021 > (https://mm.aueb.gr/publications/0a8b37c5-c814-4056-88a7-19556221728c. > pdf) > [2]https://essif-lab.eu > -- > Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile > Multimedia Laboratory Athens University of Economics and Business > https://mm.aueb.gr ------=_NextPart_000_03E9_01D7B65C.E5D69210 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEj4w ggQxMIIDGaADAgECAgEAMA0GCSqGSIb3DQEBBQUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7 SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3Jp dHkxQDA+BgNVBAMTN0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg Um9vdENBIDIwMTEwHhcNMTExMjA2MTM0OTUyWhcNMzExMjAxMTM0OTUyWjCBlTELMAkGA1UEBhMC R1IxRDBCBgNVBAoTO0hlbGxlbmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMg Q2VydC4gQXV0aG9yaXR5MUAwPgYDVQQDEzdIZWxsZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2gg SW5zdGl0dXRpb25zIFJvb3RDQSAyMDExMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA qVMA4y6m9o76YNgtlT74LCpUTs25hGGUWE+PPYvkQ/N1iY1R5MM30oqITXketxLdQ3hKipLm10jV D6Q6KUQ1uAf2aB1VzThR8IwkMYWvg8l96Xev7Rp7nRf5s504UA+mWnmRgK83rqbTMfu1JgmdPFrv UcUr35Zd6zIeAtpwSexuDMiaN4338TZgSyYsgp7QePMND2OkUTDh+SsnEgfY6r0YYpiwWTd9vu7z IFFCWoPvk7ppFfFinZ+ZOYKht3Qui9TFC3sv8MgK2j15CpqTHKUocnORQ5qn0U2FhLmpdI8UQMfc 3qxBZGy0GZsCY20kZI9EsiXqzl10DGMyXI2H5QIDAQABo4GJMIGGMA8GA1UdEwEB/wQFMAMBAf8w CwYDVR0PBAQDAgEGMB0GA1UdDgQWBBSmkUL9E2FKI54IpCnl2BMEI+5BJTBHBgNVHR4EQDA+oDww BYIDLmdyMAWCAy5ldTAGggQuZWR1MAaCBC5vcmcwBYEDLmdyMAWBAy5ldTAGgQQuZWR1MAaBBC5v cmcwDQYJKoZIhvcNAQEFBQADggEBAB/veUHhe24/soyGN0JKThw3Ho1muiSByU8SDyHAA5eGJW1d 0yIpqGyiDanrPQZbmTrHzMOaNH+rDshOHOH65NzNDb6/JP5s52vCDcgGnk6NYSimav3l9mLqGDxO oFOdsjqc66WckRa2TYLgDAVIqWz1zPjLnUm08AKl/XAD7Yohpa4ThknDM3O+hzt0ixdFJkwWkYP+ Z33NTWNn+vMDEpZ4Bo2xZ+2OP76fTwL1swkv80yH3yrLlXwBzKw2er+ic3r3j8G1mqEUso8znw3v Itxme4S9RRcGPTzKuXc0j8rqzz8xPuOI44BJJciXtZ2amU2wPPhKAJtk3Z85S9En17gwggbQMIIE uKADAgECAhBAB3aGT+I5a2zJV9kPcbUZMA0GCSqGSIb3DQEBCwUAMIGPMQswCQYDVQQGEwJHUjFE MEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0 LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBVbml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQg QnVzaW5lc3MgQ0EgUjIwHhcNMTkxMjEyMTQxNzU4WhcNMjExMjExMTQxNzU4WjCCAQkxCzAJBgNV BAYTAkdSMQ8wDQYDVQQHDAZBdGhlbnMxNDAyBgNVBAoMK0F0aGVucyBVbml2ZXJzaXR5IG9mIEVj b25vbWljcyBhbmQgQnVzaW5lc3MxQTA/BgNVBAsMOENsYXNzIEIgLSBQcml2YXRlIEtleSBjcmVh dGVkIGFuZCBzdG9yZWQgaW4gc29mdHdhcmUgQ1NQMQ8wDQYDVQQEDAZGT1RJT1kxETAPBgNVBCoM CE5JS09MQU9TMRMwEQYDVQQFEwozODY2OTQxMjIxMRgwFgYDVQQDDA9OSUtPTEFPUyBGT1RJT1kx HTAbBgkqhkiG9w0BCQEWDmZvdGlvdUBhdWViLmdyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAgLLzGBqZBB4A0EYdBSjLSUYjNMZYSS14Z4+Esf6iK7wrSw8pOfjLBMqtJOywazPxWgmm vhk6PaCLhZYgwPqdGQk3z+m3Hm2ao9fnFghTIBhXyypOJVCEVNblcY1r6+HZZLZZ/Z5NnMLuNKK+ uWQ7dRR/GZDOFGcnOtcmMx9GKrgSrawVOsghzBRg5wLbvCaCNJsJ90mRYsyUjkg9OglG2dzZ7Bi0 2BzozUwP69dFaKG7ml12C9FwQiaBURg3dDbgl7AuGY1AZcqBAPwKNni0Jkpl5XL2JzjbzQj73EbT FMrsgG1PbGw/uZgQyCqAVHS1HiIJhyMTn7cttd5CobkMMwIDAQABo4IBqTCCAaUwHwYDVR0jBBgw FoAUd2BZxxknkkBQvIKZbY8+SdAQ9CowbQYIKwYBBQUHAQEEYTBfMDoGCCsGAQUFBzAChi5odHRw Oi8vcmVwby5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhQXVlYkNBUjIuY3J0MCEGCCsGAQUFBzABhhVo dHRwOi8vb2NzcC5oYXJpY2EuZ3IwGQYDVR0RBBIwEIEOZm90aW91QGF1ZWIuZ3IwWAYDVR0gBFEw TzAIBgYEAI96AQEwQwYNKwYBBAGBzxEBAQICATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3JlcG8u aGFyaWNhLmdyL2RvY3VtZW50cy9DUFMwKQYDVR0lBCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgor BgEEAYI3CgMMMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmx2MS5oYXJpY2EuZ3IvSGFyaWNh QXVlYkNBUjIvY3JsdjEuZGVyLmNybDAdBgNVHQ4EFgQUcMJMYLF3+xjl9x4Fc4V2qRdAoVIwDgYD VR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQAo/QEb7ED5Z7e3qdVPfIdKRpnLQ+JH3V7w 4CKouEZkSjH2m+y0WOtMoF4cPCNrMH90n/IH9QuGcyYALRQTXAKsgF5s5TIeHc8fpFAesjoVjTHT ijK94b4ekh81jU/o8sRhsfWjPzAjzhSogWuh9yYox7fx0pvnux9lGE2+mVhE0xJqzP4N6zGmVsYY Og6YfOtjYK46lvT5WOKkdK9lD9S3vmws0BPOCirvIqc9/fzKngZMTcsXMEZp91z40SuUxn48P370 TKgvzIkmnDVB/iOobkdErAgp5j2o6s/Bt2m91VwLW3xOIV4F9y8BGOxsRqvRkv7wMKmhTjkAT+MV F7uw1S+vmeTeL+pdFUBAKJRizEqjCL6D7ZwpKszeMhi6Sx31ooOPpTOWtPh/fLfRRJBYNFcrYgMl Br0WWe1nIYajWskliR+5HNyNY8/zQApm9SGqr4VjaYdEwnU+NVLiZ2pikWyrg5B8QyqcJCNdZRez jOPqM6DN+t52HMSnqHFxsy6cqOfqOSAsitZT2LkBWVDj3TxkENnw04hPUS4ip48jMB0szuajEMmK qs5/uGY9EyQ3bHlDDWQxu/DULZJOcsZPX67mcOTLfXOXFnyW/gOGbvCgitlimm7xrDHmVWvB4AE7 XPK7ogjGmG1qEq7vnYOcgj93DGizi+QkmVMCJwpGYjCCBzEwggYZoAMCAQICCBjdh64fS7Z7MA0G CSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMg YW5kIFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxQDA+BgNVBAMTN0hlbGxl bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgUm9vdENBIDIwMTEwHhcNMTUw NzI4MDcxMDQ4WhcNMjMwNzI2MDcxMDQ4WjCBjzELMAkGA1UEBhMCR1IxRDBCBgNVBAoTO0hlbGxl bmljIEFjYWRlbWljIGFuZCBSZXNlYXJjaCBJbnN0aXR1dGlvbnMgQ2VydC4gQXV0aG9yaXR5MTow OAYDVQQDEzFBdGhlbnMgVW5pdmVyc2l0eSBvZiBFY29ub21pY3MgYW5kIEJ1c2luZXNzIENBIFIy MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAjTO6hsbRRbmkpEjRUM1K7/Mn2XgBgh/T p6AbDXt5rS/oFBc/GJ5bCJFc7P1d1LHMSM1VT0advzlwE2xdnR0X9ThYKIm67gOAs1RUHxLqSYcr g2qkGdm1LadSwfn8KTDAxXynmVHhduU5jOTWS/LbX18EkZQ0tWiTEHxN+Uj7RFGzPrrEC6C3x+W/ jZ9uZEfjLOxC0FHkYGndlHWh2SnoJyKvcWXE1F3DEdsGhm7gK/wxRG70U1ryihV3upd43YNdxEzB BEP2RIR8UDPLt4UpdfmmTk9uVJR6waYYtpnF10PSpuMRXNqV2dtlXCz8OEuoWFSlJbUF7VmwiZID g5P7INZ9bRWercaBquvOdDk0hBcuUfadx7TfPQHRhhUAP9UGvGcJsX7gP/3R0eUMGC6QH+Ly5LKd fHpubVABNQnXcKXgVQtjJWGObSGsnz/X3PmhF+MYlQRtrT7852Paf0xnQ1klXaLpd04jRK/EoVrJ s9jZWggPatQsX9aWuXR7xWGqOR3kT7aetAwk3FgT896eUj5V1C5eJZy9b21SJm5ux2WtmrcpCtDc YSafDaJ/0toGUPnZZnDMyyKYbuQvNu7AVYcT5uFTu84JKTqjl8jrXb4PITFN7rjKPOb0geJm+RtT De9Shan4d0vty9xWUDvMV5utJPIkreaRdGDbbNJQkP0CAwEAAaOCAocwggKDMA8GA1UdEwEB/wQF MAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR3YFnHGSeSQFC8gpltjz5J0BD0KjBGBgNV HR8EPzA9MDugOaA3hjVodHRwOi8vY3JsdjEuaGFyaWNhLmdyL0hhcmljYVJvb3RDQTIwMTEvY3Js djEuZGVyLmNybDAfBgNVHSMEGDAWgBSmkUL9E2FKI54IpCnl2BMEI+5BJTBuBggrBgEFBQcBAQRi MGAwIQYIKwYBBQUHMAGGFWh0dHA6Ly9vY3NwLmhhcmljYS5ncjA7BggrBgEFBQcwAoYvaHR0cDov L3d3dy5oYXJpY2EuZ3IvY2VydHMvSGFyaWNhUm9vdENBMjAxMS5jcnQwggE3BgNVHSAEggEuMIIB KjCCASYGBFUdIAAwggEcMDIGCCsGAQUFBwIBFiZodHRwOi8vd3d3LmhhcmljYS5nci9kb2N1bWVu dHMvQ1BTLnBocDCB5QYIKwYBBQUHAgIwgdgwShZDSGVsbGVuaWMgQWNhZGVtaWMgYW5kIFJlc2Vh cmNoIEluc3RpdHV0aW9ucyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoGJVGhpcyBjZXJ0 aWZpY2F0ZSBpcyBzdWJqZWN0IHRvIEdyZWVrIGxhd3MgYW5kIG91ciBDUFMuIFRoaXMgQ2VydGlm aWNhdGUgbXVzdCBvbmx5IGJlIHVzZWQgZm9yIGFjYWRlbWljLCByZXNlYXJjaCBvciBlZHVjYXRp b25hbCBwdXJwb3Nlcy4wLQYDVR0eBCYwJKAiMAmCB2F1ZWIuZ3IwCYEHYXVlYi5ncjAKgQguYXVl Yi5ncjANBgkqhkiG9w0BAQsFAAOCAQEAhSXJoQDbTRBYH549pfk9+3CjT+HnAcFajp60aV8UYR63 DZflolPCDagaRxADLd3SpbOuGlRGNw+MgYpAp/d6i5BfVpjMVIhp5E7zr6TDJgVIwt2UxuLejfow umCNkRJD+RrdUcLKHzcPOfSD40MRHprehXT1bvyuka26ogF6U0T2uEDoOIaObV/RS9wgGx9y63/Q Ic/tsZNQ3pzcAbTecnax6ITfSvnnfeMol6IcS+rKxPwKjPPFQq93qT8w61qe+zEx54vRwJXi241e dkTmBTJddM5Cdhxxy98xYX+eYNnf5x96vVDQ1qc2wcecMHADZBrfVV/tx0Ev6hTlYBhOmzGCBEUw ggRBAgEBMIGkMIGPMQswCQYDVQQGEwJHUjFEMEIGA1UEChM7SGVsbGVuaWMgQWNhZGVtaWMgYW5k IFJlc2VhcmNoIEluc3RpdHV0aW9ucyBDZXJ0LiBBdXRob3JpdHkxOjA4BgNVBAMTMUF0aGVucyBV bml2ZXJzaXR5IG9mIEVjb25vbWljcyBhbmQgQnVzaW5lc3MgQ0EgUjICEEAHdoZP4jlrbMlX2Q9x tRkwDQYJYIZIAWUDBAIBBQCgggJxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTIxMDkzMDIxNDAxNFowLwYJKoZIhvcNAQkEMSIEINF7ghXpvqR5shVTzvpk1khip4zM HEh6/eJ6a0p+6CM7MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMIG1BgkrBgEE AYI3EAQxgacwgaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxsZW5pYyBBY2FkZW1pYyBh bmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6MDgGA1UEAxMxQXRoZW5z IFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBSMgIQQAd2hk/iOWtsyVfZ D3G1GTCBtwYLKoZIhvcNAQkQAgsxgaeggaQwgY8xCzAJBgNVBAYTAkdSMUQwQgYDVQQKEztIZWxs ZW5pYyBBY2FkZW1pYyBhbmQgUmVzZWFyY2ggSW5zdGl0dXRpb25zIENlcnQuIEF1dGhvcml0eTE6 MDgGA1UEAxMxQXRoZW5zIFVuaXZlcnNpdHkgb2YgRWNvbm9taWNzIGFuZCBCdXNpbmVzcyBDQSBS MgIQQAd2hk/iOWtsyVfZD3G1GTANBgkqhkiG9w0BAQEFAASCAQAgLdkS6gQwRMBmvu9D8vxJRKEy /iHVLph04/HmtTW7AGwfX6vjFbXlEKnFZkz9+nDFFLbko8DppI34uSKEX8SjgcwF2iDeKnOPsRBV yNPknewH5CgP45MwkzavO53xIYqfMS9FLYT/dszH2tjZoolvO0MePyJfKu5dMnDuMFsu5yXVJsgC A5YZNejNzav2qoay4t1XvSJs8MCy+b2rxMNplLEelqclsUG8Cn+8JA7qu1Ga8eeW3MtMlQnp+lZN QcxXHtnJrX2d8xRqsTP4nRa+MHr/bNtVls2m3Dds8Y3CgiZBdNKeBqxk0ta0pof0AtXsxRVoUDkk ptxh9VC1FIx1AAAAAAAA ------=_NextPart_000_03E9_01D7B65C.E5D69210-- From nobody Thu Sep 30 17:58:27 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5877A3A0A84 for ; Thu, 30 Sep 2021 17:58:25 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 0lnN38Qa_n6c for ; Thu, 30 Sep 2021 17:58:20 -0700 (PDT) Received: from mo-csw.securemx.jp (mo-csw1114.securemx.jp [210.130.202.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37E013A0A7E for ; Thu, 30 Sep 2021 17:58:19 -0700 (PDT) Received: by mo-csw.securemx.jp (mx-mo-csw1114) id 1910wFbg027962; Fri, 1 Oct 2021 09:58:15 +0900 X-Iguazu-Qid: 2wHHCQcinec5hnIbbN X-Iguazu-QSIG: v=2; s=0; t=1633049895; q=2wHHCQcinec5hnIbbN; m=gfAj/fSnY+pOgTF6bJzV4EbOJ+W7Df//mzBPLvlOzbw= Received: from imx12-a.toshiba.co.jp (imx12-a.toshiba.co.jp [61.202.160.135]) by relay.securemx.jp (mx-mr1113) id 1910wEG5001092 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 1 Oct 2021 09:58:14 +0900 Received: from enc02.toshiba.co.jp (enc02.toshiba.co.jp [61.202.160.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by imx12-a.toshiba.co.jp (Postfix) with ESMTPS id AAB641000C0; Fri, 1 Oct 2021 09:58:14 +0900 (JST) Received: from hop101.toshiba.co.jp ([133.199.85.107]) by enc02.toshiba.co.jp with ESMTP id 1910wE8L013572; Fri, 1 Oct 2021 09:58:14 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V7GNKv1iohJQ1IfaDmP3XVuv/VE4D6Hvo0Flyh0rE/Y2KFmbcGQeIo/aCS5hm8uvTVFBj7CWKcbdEFkTo35VtSHRuZ9WQ6w5m2Rp6hArWwNM09hJ0yuQ3FUQCc0FWVupQ0NqCYZekErXpOOoCO4qEoti8GhI1HcUPB2L8yfZ5uW62YOyKLzmeV4VeQqUx6WDnBj0uZAq9B/pChoy5pWVpFS+/qatZUJWhRq/IrtlaKKR4Ilx1tWQFcKVotzx58Weq1BsZxbVFjYTA3jq+xaIZk519k795wSgWVs68b+y/A0EhQlnA6gL288D6VSawKQlcFsqs7OQqEdFq4GivYlqmw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dkSWkKiiYUBMGeLEl1mjN0MXT9IpreYaLZ9uXSavBVs=; b=i08oBss4iW17oC6knJrAVLkW5yr+OPjKh5ci6S+7v9Quq9zexHkaQ2QLfz0VH4gkfv6E3hJy7GENEzW82L0Ir871JXGAN6FvXlEAkGorwyZ7bEhyZN4yJU02m/e1G/F2J8uS2vlWpHLhDfNyD5KtkjG61E/stoLP4e96yI8YGb00Mg7bL3rzTRreo2qt+ilp6WnZkD4UFyooqSDRq3KOhzBFe+oWKv4+Vn/UOAgQg96iqSoqJ9vXlxE/4Iwbs2Ju1sp0pnpskNgLtT6lo4IlemtOE7YvaJp5TIMn719NDKNPNzGwOwXoZHPwA3ZvTCpfxHJ6kXXAMVSe0+bPPvkjKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none From: To: CC: Thread-Topic: [OAUTH-WG] self-issued access tokens Thread-Index: Ade01Nk+d5eF4L5tTXCgjU67TgIDjwAIzLwAAFmdA8A= Date: Fri, 1 Oct 2021 00:58:11 +0000 X-TSB-HOP: ON Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=toshiba.co.jp; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d1f2a38-ef86-4c05-5f2e-08d984768aa1 x-ms-traffictypediagnostic: TY1PR01MB1579: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2733; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yWm3k+OJ2IZkVYauXdwMik0JvOksSW9553zzlTu6vyQUAArTOkva6vtkO4RYxgjwf2NHND+LJuH9eyIja6GYCI1rIc1sj/MavOVgIGV5K/h8lgOX/2vRzLW1gssYVcBahprCMor4w4rhy1wiqS4AgHgKkOzK6sypQ4Wy03kyJZYVU02azzXbnmDq6M6F+k9dnIC+ZgGYgtSd1xzlJcm7+ym4MKmmZ2KrTSFGlDCuimBcVIwL0RFixqAXRl+XtORQMayoXsIPxJJCRxytm+1b+WllYqlvfXmYQcMp1a4bXM6zHqRrNjtALSmUmUpWJ2Rf/iGPVSjtcKOUiUrkMOtMbOXTJQmjN9buaGiOl//R6EqgDOmdIdCLwEszARrCr/ni1wTpB5EM68UuyGZcQUS7U30+ETAuURJlbbYp++g7T0N7CqPuXMWed1CGiEx9ZKA2koqqH7q+mUM9VJnGb2Z2Cv3Bn6D9FRpQzEk+AFIV7P8tmgnzP90j79Lf26UtjRyhwq2vFx53TGydA4qzt9nwpZUX8WrcjY4CDP0GZspl5JMxnqsJsic1LUCoog5LOEGiHs5Rn3uDRNf74WgGCboS66yWzKuZlXxhGCeTd717iuDoqTHkRI5L8OuWoOdixGbHMmJXgkjMbldBkQfv5/QKLi8Af6kIrGXKIg+y9eBsjjC1Le4V5SDmTIfzNB2BvYj2SRof2DoYJ+brs2BnP/uQyg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYCPR01MB5678.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6916009)(26005)(38070700005)(186003)(5660300002)(76116006)(6506007)(33656002)(55016002)(4744005)(8676002)(86362001)(38100700002)(53546011)(71200400001)(122000001)(52536014)(316002)(4326008)(66556008)(66476007)(64756008)(7696005)(508600001)(66446008)(8936002)(83380400001)(66946007)(9686003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZFRwamdKUFdDNkkrajlhYUJNRTd1SHpqZ1YxQjZCblhMYU1mb3ZRZmpsT3RS?= =?utf-8?B?NithSUU3S2dDMTdBcFMyeXRESk1Odk1SWmNlWC9BYWtxeUNPRHdqbEhuaFhu?= =?utf-8?B?ZTFXMGtLYU5LVU1WL2Vmb25GTjBnWnlJZzNrSmZMZ0d6TWUzcTN5d08rL25F?= =?utf-8?B?bExXZEhGYU1GTFZIS0lNYmZWS0RuaXpVSE9zZDlXYU4rS3VqRmlEcGR5dUxx?= =?utf-8?B?ZmhhV3hodERIejBveTFRK3orUjU5eFhHc21XdUxsS3drK21RWDR0YjRQOHJI?= =?utf-8?B?d3NaL3NvSmtoNVhFZGxtTy9NVmZ2dWc2VFhZbWZSR3NjYUFoYWpBaEZLb0pL?= =?utf-8?B?ekZJajBxdHRWWjJJL1hvZ21ZRkRqcUJjVmV3ZWFNdHIwOEdkdFJHQ2lOdXVm?= =?utf-8?B?UHYzaFpCbzVBa2d3bGhnd1A0cnRQNXVwTkEySVNqdlJSMWE2ZEhPbHJRTEhQ?= =?utf-8?B?NFFsc2hWL3gzYzNScXdySEhuV1owMlAzb2tWL1JSaThNM3VTbElPZlZWZ3Ny?= =?utf-8?B?SkVXQW1lWTZOM2pnLzRadXdtUG1aU25QWUNwaTE2aVFIeTB6V1REQjFMTk9W?= =?utf-8?B?a09hOHgyVXoxM3hDWk83Wks2K2lCRS81NFk3WFpNZkhOcVp5NkZzT0ozNkVz?= =?utf-8?B?c2czV24vM3hrMDBDVVZmYVl5aXlhQ2NWUHJjL1paREI2dW5oUUNQLytHK1Za?= =?utf-8?B?WFFiS09PODFlS3dOWkJNdndwWWhsMFRDdWplV0hmN0xTSkFta0V4b1RFQUxJ?= =?utf-8?B?VXFmWk9FcWwxTEpqWXdIbmUwVjQyOXBtdTFmeUVJRlpvS2gzNjNYM3VNcFFW?= =?utf-8?B?WkFvSjdkeHZBaWN6bVM2RWRUK3daeXBBUmN0dXFmV29oWUlYTWo0cjYwa1Yx?= =?utf-8?B?TFRBdDVlbnFEeFNvQnE4OFlvakNVVkNXOXhIUzZpUjZZVkZMbTBIaFJON0Fm?= =?utf-8?B?bkd4TEo0L21pVm5EKzNXM1JKOGhLVlRVek5WbnppaGpHSXlha3l3OE1zWDU5?= =?utf-8?B?Vkt6bEZGQVFoRHZwdjJUVTBLMUY4OHRPc3d6S2p4aEMwNTJyQld4N01LRVl5?= =?utf-8?B?RVh6QnQ4T2sxOElVdElSd0xLWEJlcTk5SXRDUUZQdXpIeHhmVmxRZkN1UXhy?= =?utf-8?B?ODBkUTM5bjZiYTVLWlNuR2NKS2lUU2hIMDhJWXpDQ1ZnZEhaNU1Td1VGQm9v?= =?utf-8?B?YXI1My9qTWtmQ3FRa2ZxcEFBMXZXVzl6SUF4Qm5CZXcrRU0wajZJRm4zbi81?= =?utf-8?B?YnY1L2MycTFreGcvN1hheE5zVFI0eG9PNTY5ZExHWFVvMkpoSUU0bitzWGk3?= =?utf-8?B?cGF1SGt1Z25RWDBGZmNCTFNGZHo1dWlYM1JkT0lzQVl2cmxtRmdGWmxiRGlJ?= =?utf-8?B?K25sU2FxY0x0VlpMTVE3Q3pTTHN4eVpIRlU2cmhYY2kwSXVtay9IK1J0VXEr?= =?utf-8?B?VlNnS3dxZUVyODFnUEQxY0ZodlFDbGxDdzdoMk9kUVNVMXhWdm0rdExoK3Fj?= =?utf-8?B?YUlCOGxyMG9McXBndnpETG1weE5lcDhxZU1EdW5Hc3BycjByeGVSaFg4ZTFy?= =?utf-8?B?VHNibStRaDhPbThCbEQwZWJXMUhlZGYzcmVoeWoyUUQ3VW9wLzJxdUtwNDR6?= =?utf-8?B?d3prWnc1RVA4NW52RVYyaVdQanY5UEdmQktVaCtYZG14RmxxUzN2N1cxeFdp?= =?utf-8?B?Wng4NWhuUzVPdU0wd0FvSmhvYk9vaXVLSG55dkxjT0lwdkNnVXBCQnN6cXBY?= =?utf-8?Q?6k3z7fyT//PmxkXd2A=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_TYCPR01MB56784381BE6799ADAA46E360E5AB9TYCPR01MB5678jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYCPR01MB5678.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d1f2a38-ef86-4c05-5f2e-08d984768aa1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 00:58:11.5538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6oTIWbPh/kwxlyiv4088c9jyWgPblSMaARkA3iHELJlXBo0/GSCEfakDT2PwJqYJOW/FmosUH+RBs5QOxskGHhWZkD476KbDouZdDtNE+90= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB1579 X-OriginatorOrg: toshiba.co.jp Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 01 Oct 2021 00:58:26 -0000 --_000_TYCPR01MB56784381BE6799ADAA46E360E5AB9TYCPR01MB5678jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERpY2ssDQoNCkkgYWdyZWUuIFRoZSBzY2VuYXJpbyBvZiBzZWxmLWlzc3VlZCBhY2Nl c3MgdG9rZW5zIGRvZXNuJ3QgcmVhbGx5IGZvbGxvdyB0aGUNCm1vZGVsIG9mIE9BdXRoLg0KDQpT bywgaWYgd2UgZG8gc3RhbmRhcmRpemUgc2VsZi1pc3N1ZWQgYWNjZXNzIHRva2VucywgbWF5YmUg T0FVVEggV0cgaXMgbm90IHRoZQ0KcmlnaHQgdmVudWUuIE1heWJlIEhUVFBCSVMgb3IgSFRUUEFQ SSBXR3M/DQoNCg0KVG9zaGlvIEl0bw0KDQpGcm9tOiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdt YWlsLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDI5LCAyMDIxIDM6MDYgUE0NClRv OiBpdG8gdG9zaGlvKOS8iuiXpCDkv4rlpKsg4peL77yy77yk77yj4pah77yp77y056CU4peL77yj 77yu77ysKSA8dG9zaGlvOS5pdG9AdG9zaGliYS5jby5qcD4NCkNjOiBvYXV0aEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtPQVVUSC1XR10gc2VsZi1pc3N1ZWQgYWNjZXNzIHRva2Vucw0KDQpJZiB0 aGUgY2xpZW50IGlzIHNlbmRpbmcgYSBzZWxmLXNpZ25lZCBKV1QgdG8gdGhlIFJTLCB5b3UgZXNz ZW50aWFsbHkgYXJlIGp1c3QgYXV0aGVudGljYXRpbmcgZGlyZWN0bHkgdG8gdGhlIFJTLiBOb3Qg cmVhbGx5IE9BdXRoIGFzIHRoZSBSUyBoYXMgbm90IGRlbGVnYXRlZCBhdXRob3JpemF0aW9uIGF1 dGhvcml0eSB0byB0aGUgQVMuDQoNCklmIHRoZSBjbGllbnQgc2VuZHMgYSBzZWxmLXNpZ25lZCBK V1QgKGEgUEFSKSB0byB0aGUgQVMsIGFuZCBnZXRzIGJhY2sgYW4gYWNjZXNzIHRva2VuIHRvIHBy ZXNlbnQgdG8gdGhlIFJTLCB5b3UgZ2V0IGNlbnRyYWxpemVkIGF1dGhvcml6YXRpb24gZGVjaXNp b25zLCBhIGtleSBmZWF0dXJlIG9mIE9BdXRoLg0KDQoNCg0K --_000_TYCPR01MB56784381BE6799ADAA46E360E5AB9TYCPR01MB5678jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg 44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrmuLjjgrTjgrfjg4Pjgq87DQoJ cGFub3NlLTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIOOC tOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEDvvK3vvLMg77yw44K044K344OD44KvIjt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQOa4uOOCtOOCt+ODg+OCryI7DQoJcGFub3NlLTE6MiAxMSA0IDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrjg6HjgqTjg6rjgqo7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDjg6HjgqTjg6rjgqoiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowbW07DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Iu+8re+8syDv vLDjgrTjgrfjg4Pjgq8iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MG1tOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBtbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44Kv Ijt9DQpzcGFuLjE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiLvvK3vvLMg44K044K344OD44KvIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk65ri444K044K344OD44KvO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46OTkuMjVwdCAzMC4wbW0gMzAuMG1tIDMwLjBtbTt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2Ij4NCjx2OnRleHRib3ggaW5zZXQ9IjUuODVwdCwuN3B0LDUuODVwdCwuN3B0IiAv Pg0KPC9vOnNoYXBlZGVmYXVsdHM+PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkpBIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDj grTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIERpY2ssPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8m cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SSBhZ3JlZS4gVGhlIHNjZW5hcmlvIG9mIHNlbGYtaXNzdWVkIGFjY2VzcyB0b2tlbnMgZG9l c24ndCByZWFsbHkgZm9sbG93IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPm1v ZGVsIG9mIE9BdXRoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K3 44OD44KvJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCBpZiB3ZSBkbyBzdGFuZGFyZGl6ZSBzZWxm LWlzc3VlZCBhY2Nlc3MgdG9rZW5zLCBtYXliZSBPQVVUSCBXRyBpcyBub3QgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pj gq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+cmlnaHQgdmVudWUuIE1heWJlIEhUVFBCSVMgb3IgSFRU UEFQSSBXR3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pj gq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFG NDk3RCI+VG9zaGlvIEl0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwbW0gMG1tIDBtbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERpY2sgSGFyZHQgJmx0 O2RpY2suaGFyZHRAZ21haWwuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg U2VwdGVtYmVyIDI5LCAyMDIxIDM6MDYgUE08YnI+DQo8Yj5Ubzo8L2I+IGl0byB0b3NoaW8oPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7kvIrol6Q8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5L+K5aSrPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiDil4s8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPu+8su+8pO+8ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj7ilqE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPu+8qe+8tOeg lDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7il4s8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPu+8o++8ru+8rDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4pDQogJmx0O3Rvc2hpbzkuaXRvQHRvc2hpYmEuY28uanAmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdH XSBzZWxmLWlzc3VlZCBhY2Nlc3MgdG9rZW5zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgY2xpZW50IGlzIHNlbmRpbmcgYSBzZWxmLXNpZ25l ZCBKV1QgdG8gdGhlIFJTLCB5b3UgZXNzZW50aWFsbHkgYXJlIGp1c3QgYXV0aGVudGljYXRpbmcg ZGlyZWN0bHkgdG8gdGhlIFJTLiBOb3QgcmVhbGx5IE9BdXRoIGFzIHRoZSBSUyBoYXMgbm90IGRl bGVnYXRlZCBhdXRob3JpemF0aW9uIGF1dGhvcml0eSB0byB0aGUgQVMuJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgY2xpZW50IHNl bmRzIGEgc2VsZi1zaWduZWQgSldUIChhIFBBUikgdG8gdGhlIEFTLCBhbmQgZ2V0cyBiYWNrIGFu IGFjY2VzcyB0b2tlbiB0byBwcmVzZW50IHRvIHRoZSBSUywgeW91IGdldCBjZW50cmFsaXplZCBh dXRob3JpemF0aW9uIGRlY2lzaW9ucywgYSBrZXkgZmVhdHVyZSBvZiBPQXV0aC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_TYCPR01MB56784381BE6799ADAA46E360E5AB9TYCPR01MB5678jpnp_-- From nobody Thu Sep 30 18:07:19 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFC73A0ADE for ; Thu, 30 Sep 2021 18:07:16 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3_8WYlQvB8r for ; Thu, 30 Sep 2021 18:07:11 -0700 (PDT) Received: from mo-csw.securemx.jp (mo-csw1114.securemx.jp [210.130.202.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB153A0AAB for ; Thu, 30 Sep 2021 18:07:11 -0700 (PDT) Received: by mo-csw.securemx.jp (mx-mo-csw1114) id 191175x7007032; Fri, 1 Oct 2021 10:07:06 +0900 X-Iguazu-Qid: 2wHHhCFIJ3aIANaj7M X-Iguazu-QSIG: v=2; s=0; t=1633050425; q=2wHHhCFIJ3aIANaj7M; m=O40DX/g6R5JnOuME1OhpHrwT75IYZXxID7dYkacwVuU= Received: from imx2-a.toshiba.co.jp (imx2-a.toshiba.co.jp [106.186.93.35]) by relay.securemx.jp (mx-mr1111) id 1911741a037048 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 1 Oct 2021 10:07:05 +0900 Received: from enc01.toshiba.co.jp (enc01.toshiba.co.jp [106.186.93.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by imx2-a.toshiba.co.jp (Postfix) with ESMTPS id A9C5E100122; Fri, 1 Oct 2021 10:07:04 +0900 (JST) Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.toshiba.co.jp with ESMTP id 1911745g028040; Fri, 1 Oct 2021 10:07:04 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VjNXhHR/8SwIiEoNwtkm56w1kTdGtBsixrtR8SB3M4Gc1S+As3Jti2LI16urbEEgxHooyBdae5GkFxUSH9i2YT/Z1aIZBuQlkpWcQoIlrKWU3WecZGW1ish1DFATBMJZSBPGKHpdP4mTXQteMVPadv/NRA3yaKNf2EZtB3d76xx6MQJI96grWDjJ8xcNYndCOmJ8P1/Y/zmKYUlojL493WU+MYFaatgr1h17H+H2Bob74O6XmyjrKXon5488Hw3er1hlqH4I98YJjNXIJPQyTXbj7jSKaVn5oQLbfC8RYeakVq88aWKgCp8eIK6sAkdLAHKVyadrTnLxFwd8ay9qhA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=lk5rDGuOmDfT7bVw56QjPIV1spzy9MXDdiTY8SyzJVw=; b=QH5lDb90gldpK7TCtJDhBZ2Nt0YtmIXTcfmQGvW6BdUmEpCRHaDMfmRGF5c8ZvEcSOWqDS8Ki9qhnobenUaO923BJhwyiJG/FcB9waRlBfHnRrrxAKZNrXTp+1WQboeJAwA10wTVR6yLDciwozPj278TDIOBeWbtmc/Uy5CKwdMNZ6biwDSrnglMQtGHcBxAPOj26swgM5ajqiyMaE+ybkooe0nPK0fgFKZ/4DHSeU4TtmCVWSzkCfp+S3VphxZd2QlrZw5pg8oop59cRgnFdgmMh6MgCmIV0rvfVgefDwKLSuyiaI6GUs0oyRf/K7UXgWh/tCw2NJePUSOSfUSfkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none From: To: , CC: Thread-Topic: [OAUTH-WG] self-issued access tokens Thread-Index: Ade01Nk+d5eF4L5tTXCgjU67TgIDjwAJDpkAABNWwwAARlm3oA== Date: Fri, 1 Oct 2021 01:07:00 +0000 X-TSB-HOP: ON Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=toshiba.co.jp; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 544eab6c-a785-48ab-048e-08d98477c608 x-ms-traffictypediagnostic: TY2PR01MB2233: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /JBe1e81jYCg5sRKnS0rfEMKUhDP0bFsVWBkAbMwqin9C4Km/5IKTE1bn+F8PRiIvWjH7j4S7fw1vrPcXEprGFA/dcZAdCG4KuNAhu1kb2diLGwHVIEFff9DFfrN5dnPQZMCYxG5mbAHgS2img4esmrivWHVS01ChpFooaF5M52yStN2ZrK3UUfIvIJcbojoAqnm1q6wlbKtQbekaEhfi4DqNymzq3jRzMrHrvN10Vz/31/hMLi78mhe1iY+pViYGokqVPgf7Q4Pfxxzb2DRgasn9tGqVYCQ0yrvUxjS4qz1SlNi4whQ+Un9uAFVUmmF+fTuGg4EFm+zfYFMZAWyCBnBSrAUPpmxp9FliFIwMsJ6cQlg1zQt3a3JF2h9R2oMnLDv/d0uft4/1jNYkb1O+LJ8g5CJXIjgBnhIJv/7f9o7V9MC4QP57TU6qNKyTZ+x3Puz4wv0P5Vx+W2Xbl1VBAQHTtXQo0ncrMHYY2MAwa8phqtr5e1zvSDwxEYdlcbiYUDPZIzl0wX2SvG+x0/s9rpkcLLrDHfNzMjl/UuAibUc/my2NaAsj4endkLL4F0h6O2CeJIRetAvZmgug47gmcDF8Y8EzMG2vnSUR5yuzxPAQJxA5Ce7pzf5MDw27ajpGwj17EdpimB3aG8b8taG3IPK6rrdNl9prY8UtxagjxLXrIBNx8MHdH90AGLNOZfR6Lna58KHWyp9tRpxMlnl9aO0Sjq18AkDFPbp9pcrrW9jbJJT2FTkPyQ3RUWKFN46ZkUUqtB1MuqIQC0dNaq2nauhnqzPA8jaLTyp8MngJV4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYCPR01MB5678.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(5660300002)(7696005)(8936002)(8676002)(110136005)(166002)(2906002)(508600001)(316002)(186003)(966005)(66476007)(21615005)(6506007)(53546011)(52536014)(26005)(33656002)(66446008)(64756008)(76116006)(66556008)(66946007)(38070700005)(86362001)(38100700002)(122000001)(9686003)(71200400001)(55016002)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NTBRdGxPREs5cWRuSThxc00yWFF1QWdSVXZuK3NjYzVpdkZFSkVnU2kxc1o0?= =?utf-8?B?YzRkOEh3YlVnYlp3bUJDOGJkcUExTTdFMVpFTVZHNTNlZFBYclNOTUpvVWFr?= =?utf-8?B?bUtSWkpSdkNhWkx4VzA3UTByd3RHTzVzQ1BadDdyMStqYXpoY1NXUzdXckdw?= =?utf-8?B?SkZLZjQybnV4U05EdG5sYmo5OTNZUjRObVdjRktldkJ3RWNlNFhRNm1nTG92?= =?utf-8?B?U1NMRmRKK2tiajZEODZ4QUMydEhJY2FtdkF1UjVGKzdFc1FiRi9QazFZejU1?= =?utf-8?B?dVRSOWt0MW1yK0xtWkNQSXkxUS9lMTZ6M21lL2xGVXlmNHIrYndBWUhrMzZ6?= =?utf-8?B?dDByN082Zmoyc3hudDlPQmNpNDd1OWpibm40cW9TUkhZcUhuU3NqK2x0ZjNy?= =?utf-8?B?bmFEU2l6KzBtb05SWlhPSmNvaGRzSXNnYXZ5ODFVYnlCdGtJSGIrZFZBK1JX?= =?utf-8?B?TTZlTUlGSkZzSjM2WVZuM0I1MXJiS1puakZaWGpUZG9HMXozRlFPSmhZRmJ1?= =?utf-8?B?ZWQ1QnhkVTBNajRUTW8xa0pUR0FDR0FCdkNSdWlOSWcrRFVyeWExdzV5ZUR4?= =?utf-8?B?cmt5T2J6LzMzMEoxbWlqWVJoRkJYa3M4Smk4eHBITjFwQkNYM3VNdTJGSnph?= =?utf-8?B?b3VWUC9oTURZd0w0bkR5ZURGQndtUERkc1U4cWFnd1ErZlJKNGJocWMxajI4?= =?utf-8?B?KytweTdEODAwdCtWZWVnLzRFQnVRUXVOb3BwWDZIV0Vic0JZbGt0eVdJb0NV?= =?utf-8?B?K1J6RTYrZDhhcTc4TEFVYzdqK1drb1FvMCtjbkYxOE1CQWFOa1V6L1l5Vkk0?= =?utf-8?B?TWRkK2ZycngwQ0JQOC9ncUpKQWF0WXNTNHJqWFIwUDk5QUg2TWhRQUtSVjkx?= =?utf-8?B?UGUvOTIyODF2YzJYU0d5WHZTYW5SRzZLY2VlN29Pd0F3NW5GaWxtT3M3c05Z?= =?utf-8?B?eTlIMVJmaE1OSGY0WGRJWDZ4b21oREhnOXc0VG9MNXFha1hza3YrUTRmbnNF?= =?utf-8?B?MlI0UWVtcVk1V1FxZGcyK2Z2bVBxVEt1MDNhbWNKa1ZsZ014eW82bjFCWkZF?= =?utf-8?B?QjllZzdQMkhYZ1Nka3IvcVVrTGZnaVpJb08yOWVJSGlOR1VLTVFySEE3dVQv?= =?utf-8?B?ZS9MNUNHRnNkWlRBbkpQeVJHUDIwYXRFUldQRmN5M1ZRUkRPcXZjMEhodHhr?= =?utf-8?B?UHoxd2VCSFU2eTYxd0VFM0dkOFNlb25seHdsYy81MU8vM0x0U1AvR3A3dXAw?= =?utf-8?B?MWozQ3BQcGYzSkNKNGhBRDl6QTB3aFYzNGNlM3hodGY4bUpSRkI5ZWcwZlRk?= =?utf-8?B?bTlGbnRzOWlPVEJkWTFtbjZyVkRzK3hDajdzMUdBdTlZejVwNjdUb3FQQURq?= =?utf-8?B?SzA0WWNhTDl6WWJMby8ybE9tVEZzYWZLR29MaDRZVEUrRmlvZnY2MUtEQnJF?= =?utf-8?B?NVNwcFBuc0ZFQ200c2FRZ1J4U3BFRVJPdTl0bHJXSWUwRmI0TE55Um1LSWtj?= =?utf-8?B?bzM2cHN3Z0hLTm55aFBPMU1IUWh5d1JyWDJHNnZLSUhEZ3lERjR4b0drRmRC?= =?utf-8?B?SjFPT2lSd3ArK2oxbXZMNUp2dFpNaFFaYnh4NXhlVkJzUk5kb3ZMbk1mZXhn?= =?utf-8?B?c0hWWFBKcjdCd25zdWNnQ3E5VDQyZ3QxbGlIUHNJNFI2ZzFvUHJ0ZFdPemdq?= =?utf-8?B?eDI4Zzk4bVAvTjc4RlNKa1RFK1FSQTBIL2o0UEdyNVpZWCt1b0hHbDRlMkVT?= =?utf-8?Q?BzQyeWk69wPw1+e1VE=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_TYCPR01MB5678C7E6F314225FE6BA1765E5AB9TYCPR01MB5678jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYCPR01MB5678.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 544eab6c-a785-48ab-048e-08d98477c608 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 01:07:00.7068 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jmBZ2kvO0l7mSDOqzx8fkDXEMRg8atwTjjWudfB0IQF88daqTuAbUt5iWuFZQ0bB2Ytgo7Si6fq13iMWZd8Qn7ANbFGfkaZlidXcYJMaBw0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2233 X-OriginatorOrg: toshiba.co.jp MSSCP.TransferMailToMossAgent: 103 Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 01 Oct 2021 01:07:17 -0000 --_000_TYCPR01MB5678C7E6F314225FE6BA1765E5AB9TYCPR01MB5678jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBjb21tZW50LCBWaXR0b3JpbywNCg0KWWVzLCB3ZSBuZWVkIHRvIGJlIGNhcmVm dWwgYWJvdXQgcmVwbGF5IGF0dGFja3Mgb24gc2VsZi1pc3N1ZWQgYWNjZXNzIHRva2Vucy4gSQ0K dGhpbmsgRFBvUCBQcm9vZiBwcm92aWRlcyBhIGdvb2QgKGlmIG5vdCBwZXJmZWN0KSBwcm90ZWN0 aW9uIGFnYWluc3QgaXQgYmVjYXVzZQ0KaXQgY29udGFpbnMgcmljaCBjb250ZXh0IGFib3V0IHRo ZSByZXF1ZXN0Lg0KDQoNClRoYW5rcyBmb3IgdGhlIHBvaW50ZXIsIFNhc2NoYSwNCkknbGwgbG9v ayBhdCBpdC4NCg0KDQpUb3NoaW8gSXRvDQoNCkZyb206IFNhc2NoYSBQcmVpYmlzY2ggPHNhc2No YXByZWliaXNjaEBnbWFpbC5jb20+DQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDMwLCAyMDIx IDEyOjI3IEFNDQpUbzogVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlvPTQwYXV0aDAuY29tQGRt YXJjLmlldGYub3JnPg0KQ2M6IGl0byB0b3NoaW8o5LyK6JekIOS/iuWkqyDil4vvvLLvvKTvvKPi lqHvvKnvvLTnoJTil4vvvKPvvK7vvKwpIDx0b3NoaW85Lml0b0B0b3NoaWJhLmNvLmpwPjsgSUVU RiBvYXV0aCBXRyA8b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBzZWxm LWlzc3VlZCBhY2Nlc3MgdG9rZW5zDQoNClZpdHRvcmlvLA0KDQpJIHdyb3RlIGFuIGFwcHJvYWNo IHdoZXJlIGEgY2xpZW50IHdvdWxkIHJlY2VpdmUgYSBncmFudCBieSB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgYnV0IGlzc3VlcyB0aGUgdG9rZW4gaXRzZWxmLiBUaGUgcG9zdCBjYW4gYmUgZm91 bmQgaGVyZToNCmh0dHBzOi8vb2F1dGguYmxvZy9vYXV0aGJsb2cuanNwIChmYW5jeSBuYW1lOiBT ZXJ2ZXJsZXNzIFRva2VuIElzc3VhbmNlKSBJIHByZXNlbnRlZCB0aGUgaWRlYSBhdCBJSVcgcmln aHQgYmVmb3JlIEkgd3JvdGUgdGhlIHBvc3QuDQoNCkkgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkIHdv cmsgbmljZWx5IGFuZCB3b3VsZCBhdm9pZCB0aGUgbmVlZCBmb3IgYW4gYXV0aG9yaXphdGlvbiBz ZXJ2ZXJzIHRvIG1hbmFnZSBhY2Nlc3NfdG9rZW4uDQoNClJlZ2FyZHMsDQpTYXNjaGENCg0KDQpP biBUdWUsIDI4IFNlcHQgMjAyMSBhdCAyMzoxMywgVml0dG9yaW8gQmVydG9jY2kgPFZpdHRvcmlv PTQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGF1dGgwLmNvbUBkbWFyYy5pZXRm Lm9yZz4+IHdyb3RlOg0KSGkgVG9zaGlvLA0KVGhlIHNjZW5hcmlvIHlvdSBkZXNjcmliZSBpcyBj b21wYXJhYmxlIHRvIGh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1zZWxm LWlzc3VlZC12Mi0xXzAuaHRtbCwgYXQgbGVhc3QgaW4gdGVybXMgb2YgdmFsaWRhdGlvbiBsb2dp Yy4gUGxlYXNlIG5vdGUgdGhhdCBtb3N0IG9mIHRoZSB2YWxpZGF0aW9uIHNvZnR3YXJlIGluIGNv bW1vbiB1c2UgdG9kYXkgZXhwZWN0cyB0byB3b3JrIHdpdGgganVzdCBhIGhhbmRmdWwgb2Yga2V5 cywgdHlwaWNhbGx5IG9uZSBwcm92aWRlciBhbmQgYWxsb3dhbmNlIGZvciByb3RhdGlvbiwgaGVu Y2UgaXQgbWlnaHQgbm90IGJlIHRyaXZpYWwgdG8gcmVwdXJwb3NlIGl0IHRvIHBlcmZvcm0gbGFy Z2UgdGFibGUgc2NhbnMgaW4gc2NlbmFyaW9zIHdoZXJlIHlvdSBoYXZlIG1hbnkgY2xpZW50cyBh bmQgY29ycmVzcG9uZGluZyBrZXlzLg0KQWxzbywgUHJhYmF0aCdzIGJsb2cgbWFrZXMgYSBzdGF0 ZW1lbnQgdGhhdCwgSSBiZWxpZXZlLCBvdmVyc3RhdGVzIHdoYXQgY2FuIGJlIGFjaGlldmVkIHdp dGggdGhpcyBhcHByb2FjaDogaGUgc2F5cyB0aGF0IHRoaXMgY2FuIGJlIGEgcmVwbGFjZW1lbnQg Zm9yIFRMUyBtdXR1YWwgYXV0aGVudGljYXRpb24sIGJ1dCBpdCBpc24ndCByZWFsbHkgdGhlIGNh c2UgYXMgeW91IGFyZSBzdGlsbCBkZWFsaW5nIHdpdGggYSBiZWFyZXIgdG9rZW4sIHdoaWNoIGNh biBiZSByZXBsYXllZCBhZnRlciBpc3N1YW5jZSBoZW5jZSBvZmZlcmluZyBsZXNzIGd1YXJhbnRl ZXMgdGhhbiBtdXR1YWwgVExTLg0KDQoNCk9uIFR1ZSwgU2VwIDI4LCAyMDIxIGF0IDY6NTQgUE0g PHRvc2hpbzkuaXRvQHRvc2hpYmEuY28uanA8bWFpbHRvOnRvc2hpbzkuaXRvQHRvc2hpYmEuY28u anA+PiB3cm90ZToNCkhpIE9BdXRoIGZvbGtzLA0KDQpJIGhhdmUgYSBxdWVzdGlvbi4gSXMgdGhl cmUgKG9yIHdhcyB0aGVyZSkgYW55IHN0YW5kYXJkaXppbmcgZWZmb3J0IGZvcg0KInNlbGYtaXNz dWVkIGFjY2VzcyB0b2tlbnMiPw0KDQpTZWxmLWlzc3VlZCBhY2Nlc3MgdG9rZW5zIGFyZSBtZW50 aW9uZWQgaW4gYSBibG9nIHBvc3QgYnkgUC4gU2lyaXdhcmRlbmEgaW4gMjAxNA0KWyoxXS4gSXQn cyBhbiBBY2Nlc3MgVG9rZW4gaXNzdWVkIGJ5IHRoZSBDbGllbnQgYW5kIHNlbnQgdG8gdGhlIFJl c291cmNlIFNlcnZlci4NClRoZSB0b2tlbiBpcyBiYXNpY2FsbHkgYSBzaWduZWQgZG9jdW1lbnQg KGUuZy4gSldUKSBieSB0aGUgcHJpdmF0ZSBrZXkgb2YgdGhlDQpDbGllbnQuIFRoZSBSZXNvdXJj ZSBTZXJ2ZXIgdmVyaWZpZXMgdGhlIHRva2VuIHdpdGggdGhlIHB1YmxpYyBrZXksIHdoaWNoIGlz DQpwcm92aXNpb25lZCBpbiB0aGUgUlMgaW4gYWR2YW5jZS4NCg0KSSB0aGluayBzZWxmLWlzc3Vl ZCBhY2Nlc3MgdG9rZW5zIGFyZSBoYW5keSByZXBsYWNlbWVudCBmb3IgQ2xpZW50IENyZWRlbnRp YWxzDQpHcmFudCBmbG93IGluIHNpbXBsZSBkZXBsb3ltZW50cywgd2hlcmUgaXQncyBub3Qgc28g bmVjZXNzYXJ5IHRvIHNlcGFyYXRlIEFTIGFuZA0KUlMuIEluIGZhY3QsIEdvb2dsZSBzdXBwb3J0 cyB0aGlzIHR5cGUgb2YgYXV0aGVudGljYXRpb24gZm9yIHNvbWUgc2VydmljZXMNClsqMl1bKjNd LiBJJ20gd29uZGVyaW5nIGlmIHRoZXJlIGFyZSBhbnkgb3RoZXIgc2VydmljZXMgc3VwcG9ydGlu ZyBzZWxmLXNpZ25lZA0KYWNjZXNzIHRva2Vucy4NCg0KQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21l Lg0KDQpbKjFdOiBodHRwczovL3dzbzIuY29tL2xpYnJhcnkvYmxvZy1wb3N0LzIwMTQvMTAvYmxv Zy1wb3N0LXNlbGYtaXNzdWVkLWFjY2Vzcy10b2tlbnMvDQpbKjJdOiBodHRwczovL2RldmVsb3Bl cnMuZ29vZ2xlLmNvbS9pZGVudGl0eS9wcm90b2NvbHMvb2F1dGgyL3NlcnZpY2UtYWNjb3VudCNq d3QtYXV0aA0KWyozXTogaHR0cHM6Ly9nb29nbGUuYWlwLmRldi9hdXRoLzQxMTENCg0KLS0tLS0t LS0tLS0tLQ0KVG9zaGlvIEl0bw0KUmVzZWFyY2ggYW5kIERldmVsb3BtZW50IENlbnRlcg0KVG9z aGliYSBDb3Jwb3JhdGlvbg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_TYCPR01MB5678C7E6F314225FE6BA1765E5AB9TYCPR01MB5678jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg 44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi77yt77yzIO+8sOOCtOOCt+OD g+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIOOCtOOCt+ODg+OCryI7DQoJcGFub3Nl LTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDv vK3vvLMg77yw44K044K344OD44KvIjt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuODoeOC pOODquOCqjsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQOODoeOCpOODquOCqiI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBtbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBtbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowbW07DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi77yt77yzIO+8sOOCtOOC t+ODg+OCryI7fQ0Kc3Bhbi4xOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToi77yt77yzIOOCtOOCt+ODg+OCryI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTrm uLjjgrTjgrfjg4Pjgq87fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo5OS4yNXB0IDMwLjBtbSAzMC4wbW0gMzAuMG1tO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiPg0K PHY6dGV4dGJveCBpbnNldD0iNS44NXB0LC43cHQsNS44NXB0LC43cHQiIC8+DQo8L286c2hhcGVk ZWZhdWx0cz48L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iSkEiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgY29tbWVudCwgVml0dG9yaW8sPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8m cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3 RCI+WWVzLCB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgYWJvdXQgcmVwbGF5IGF0dGFja3Mgb24gc2Vs Zi1pc3N1ZWQgYWNjZXNzIHRva2Vucy4gSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PnRoaW5rIERQb1AgUHJvb2YgcHJvdmlkZXMgYSBnb29kIChpZiBub3QgcGVyZmVjdCkgcHJvdGVj dGlvbiBhZ2FpbnN0IGl0IGJlY2F1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdEIj5p dCBjb250YWlucyByaWNoIGNvbnRleHQgYWJvdXQgdGhlIHJlcXVlc3QuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8 re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgcG9p bnRlciwgU2FzY2hhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDvvvK3vvLMg44K044K344OD44KvJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkknbGwgbG9vayBh dCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt 77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdE Ij5Ub3NoaW8gSXRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBTYXNjaGEgUHJlaWJpc2NoICZsdDtzYXNjaGFwcmVpYmlzY2hAZ21haWwuY29tJmd0Ow0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMjEgMTI6MjcgQU08 YnI+DQo8Yj5Ubzo8L2I+IFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpbz00MGF1dGgwLmNv bUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGl0byB0b3NoaW8oPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7kvIrol6Q8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+5L+K5aSrPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiDil4s8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPu+8su+8pO+8ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij7ilqE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPu+8qe+8tOeglDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7il4s8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPu+8o++8ru+8rDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4pDQogJmx0O3Rvc2hpbzkuaXRvQHRvc2hpYmEuY28uanAmZ3Q7OyBJRVRGIG9hdXRoIFdH ICZsdDtvYXV0aEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gc2VsZi1pc3N1ZWQgYWNjZXNzIHRva2VuczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlZp dHRvcmlvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd3JvdGUg YW4gYXBwcm9hY2ggd2hlcmUgYSBjbGllbnQgd291bGQgcmVjZWl2ZSBhIGdyYW50IGJ5IHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBidXQgaXNzdWVzIHRoZSB0b2tlbiBpdHNlbGYuIFRoZSBwb3N0 IGNhbiBiZSBmb3VuZCBoZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczov L29hdXRoLmJsb2cvb2F1dGhibG9nLmpzcCI+aHR0cHM6Ly9vYXV0aC5ibG9nL29hdXRoYmxvZy5q c3A8L2E+IChmYW5jeSBuYW1lOiBTZXJ2ZXJsZXNzIFRva2VuIElzc3VhbmNlKSBJIHByZXNlbnRl ZCB0aGUgaWRlYSBhdCBJSVcgcmlnaHQgYmVmb3JlIEkgd3JvdGUgdGhlIHBvc3QuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGJlbGlldmUgdGhhdCBp dCB3b3VsZCB3b3JrIG5pY2VseSBhbmQgd291bGQgYXZvaWQgdGhlIG5lZWQgZm9yIGFuIGF1dGhv cml6YXRpb24gc2VydmVycyB0byBtYW5hZ2UgYWNjZXNzX3Rva2VuLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+U2FzY2hhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCAyOCBTZXB0IDIwMjEgYXQg MjM6MTMsIFZpdHRvcmlvIEJlcnRvY2NpICZsdDtWaXR0b3Jpbz08YSBocmVmPSJtYWlsdG86NDBh dXRoMC5jb21AZG1hcmMuaWV0Zi5vcmciPjQwYXV0aDAuY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBt bSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowbW0iPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBUb3NoaW8sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgc2NlbmFyaW8geW91IGRlc2NyaWJlIGlzIGNvbXBhcmFibGUmbmJzcDt0 byZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1z ZWxmLWlzc3VlZC12Mi0xXzAuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vb3BlbmlkLm5l dC9zcGVjcy9vcGVuaWQtY29ubmVjdC1zZWxmLWlzc3VlZC12Mi0xXzAuaHRtbDwvYT4sIGF0IGxl YXN0IGluIHRlcm1zDQogb2YgdmFsaWRhdGlvbiBsb2dpYy4gUGxlYXNlIG5vdGUgdGhhdCBtb3N0 IG9mIHRoZSB2YWxpZGF0aW9uIHNvZnR3YXJlIGluIGNvbW1vbiB1c2UgdG9kYXkgZXhwZWN0cyB0 byB3b3JrIHdpdGgganVzdCBhIGhhbmRmdWwgb2Yga2V5cywgdHlwaWNhbGx5IG9uZSBwcm92aWRl ciBhbmQgYWxsb3dhbmNlIGZvciByb3RhdGlvbiwgaGVuY2UgaXQgbWlnaHQgbm90IGJlIHRyaXZp YWwgdG8gcmVwdXJwb3NlIGl0IHRvIHBlcmZvcm0gbGFyZ2UgdGFibGUgc2NhbnMNCiBpbiBzY2Vu YXJpb3Mgd2hlcmUgeW91IGhhdmUgbWFueSBjbGllbnRzIGFuZCBjb3JyZXNwb25kaW5nIGtleXMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsc28sIFByYWJhdGgncyBibG9nIG1ha2VzIGEgc3RhdGVt ZW50IHRoYXQsIEkgYmVsaWV2ZSwgb3ZlcnN0YXRlcyB3aGF0IGNhbiBiZSBhY2hpZXZlZCB3aXRo IHRoaXMgYXBwcm9hY2g6IGhlIHNheXMgdGhhdCB0aGlzIGNhbiBiZSBhIHJlcGxhY2VtZW50IGZv ciBUTFMgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLCBidXQgaXQgaXNuJ3QgcmVhbGx5IHRoZSBjYXNl IGFzIHlvdSBhcmUNCiBzdGlsbCBkZWFsaW5nIHdpdGggYSBiZWFyZXIgdG9rZW4sIHdoaWNoJm5i c3A7Y2FuIGJlIHJlcGxheWVkIGFmdGVyIGlzc3VhbmNlIGhlbmNlIG9mZmVyaW5nIGxlc3MgZ3Vh cmFudGVlcyB0aGFuIG11dHVhbCBUTFMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBTZXAg MjgsIDIwMjEgYXQgNjo1NCBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvc2hpbzkuaXRvQHRvc2hp YmEuY28uanAiIHRhcmdldD0iX2JsYW5rIj50b3NoaW85Lml0b0B0b3NoaWJhLmNvLmpwPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBt bSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowbW0iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIE9BdXRoIGZvbGtzLDxicj4N Cjxicj4NCkkgaGF2ZSBhIHF1ZXN0aW9uLiBJcyB0aGVyZSAob3Igd2FzIHRoZXJlKSBhbnkgc3Rh bmRhcmRpemluZyBlZmZvcnQgZm9yPGJyPg0KJnF1b3Q7c2VsZi1pc3N1ZWQgYWNjZXNzIHRva2Vu cyZxdW90Oz88YnI+DQo8YnI+DQpTZWxmLWlzc3VlZCBhY2Nlc3MgdG9rZW5zIGFyZSBtZW50aW9u ZWQgaW4gYSBibG9nIHBvc3QgYnkgUC4gU2lyaXdhcmRlbmEgaW4gMjAxNDxicj4NClsqMV0uIEl0 J3MgYW4gQWNjZXNzIFRva2VuIGlzc3VlZCBieSB0aGUgQ2xpZW50IGFuZCBzZW50IHRvIHRoZSBS ZXNvdXJjZSBTZXJ2ZXIuPGJyPg0KVGhlIHRva2VuIGlzIGJhc2ljYWxseSBhIHNpZ25lZCBkb2N1 bWVudCAoZS5nLiBKV1QpIGJ5IHRoZSBwcml2YXRlIGtleSBvZiB0aGU8YnI+DQpDbGllbnQuIFRo ZSBSZXNvdXJjZSBTZXJ2ZXIgdmVyaWZpZXMgdGhlIHRva2VuIHdpdGggdGhlIHB1YmxpYyBrZXks IHdoaWNoIGlzPGJyPg0KcHJvdmlzaW9uZWQgaW4gdGhlIFJTIGluIGFkdmFuY2UuPGJyPg0KPGJy Pg0KSSB0aGluayBzZWxmLWlzc3VlZCBhY2Nlc3MgdG9rZW5zIGFyZSBoYW5keSByZXBsYWNlbWVu dCBmb3IgQ2xpZW50IENyZWRlbnRpYWxzPGJyPg0KR3JhbnQgZmxvdyBpbiBzaW1wbGUgZGVwbG95 bWVudHMsIHdoZXJlIGl0J3Mgbm90IHNvIG5lY2Vzc2FyeSB0byBzZXBhcmF0ZSBBUyBhbmQ8YnI+ DQpSUy4gSW4gZmFjdCwgR29vZ2xlIHN1cHBvcnRzIHRoaXMgdHlwZSBvZiBhdXRoZW50aWNhdGlv biBmb3Igc29tZSBzZXJ2aWNlczxicj4NClsqMl1bKjNdLiBJJ20gd29uZGVyaW5nIGlmIHRoZXJl IGFyZSBhbnkgb3RoZXIgc2VydmljZXMgc3VwcG9ydGluZyBzZWxmLXNpZ25lZDxicj4NCmFjY2Vz cyB0b2tlbnMuPGJyPg0KPGJyPg0KQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLjxicj4NCjxicj4N ClsqMV06IDxhIGhyZWY9Imh0dHBzOi8vd3NvMi5jb20vbGlicmFyeS9ibG9nLXBvc3QvMjAxNC8x MC9ibG9nLXBvc3Qtc2VsZi1pc3N1ZWQtYWNjZXNzLXRva2Vucy8iIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vd3NvMi5jb20vbGlicmFyeS9ibG9nLXBvc3QvMjAxNC8xMC9ibG9nLXBvc3Qtc2Vs Zi1pc3N1ZWQtYWNjZXNzLXRva2Vucy88L2E+PGJyPg0KWyoyXTogPGEgaHJlZj0iaHR0cHM6Ly9k ZXZlbG9wZXJzLmdvb2dsZS5jb20vaWRlbnRpdHkvcHJvdG9jb2xzL29hdXRoMi9zZXJ2aWNlLWFj Y291bnQjand0LWF1dGgiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGV2ZWxvcGVycy5nb29n bGUuY29tL2lkZW50aXR5L3Byb3RvY29scy9vYXV0aDIvc2VydmljZS1hY2NvdW50I2p3dC1hdXRo PC9hPjxicj4NClsqM106IDxhIGhyZWY9Imh0dHBzOi8vZ29vZ2xlLmFpcC5kZXYvYXV0aC80MTEx IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9nb29nbGUuYWlwLmRldi9hdXRoLzQxMTE8L2E+PGJy Pg0KPGJyPg0KLS0tLS0tLS0tLS0tLTxicj4NClRvc2hpbyBJdG88YnI+DQpSZXNlYXJjaCBhbmQg RGV2ZWxvcG1lbnQgQ2VudGVyPGJyPg0KVG9zaGliYSBDb3Jwb3JhdGlvbjxicj4NCjxicj4NCjxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_TYCPR01MB5678C7E6F314225FE6BA1765E5AB9TYCPR01MB5678jpnp_-- From nobody Thu Sep 30 18:15:01 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013483A0B68 for ; Thu, 30 Sep 2021 18:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 N7TySrfMYSCZ for ; Thu, 30 Sep 2021 18:14:54 -0700 (PDT) Received: from mo-csw.securemx.jp (mo-csw1115.securemx.jp [210.130.202.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5533A0B51 for ; Thu, 30 Sep 2021 18:14:47 -0700 (PDT) Received: by mo-csw.securemx.jp (mx-mo-csw1115) id 1911EMcj029372; Fri, 1 Oct 2021 10:14:22 +0900 X-Iguazu-Qid: 2wHHa7GsP30pgC08yX X-Iguazu-QSIG: v=2; s=0; t=1633050861; q=2wHHa7GsP30pgC08yX; m=T17WMpiyyrbKFgzgPMDfU96RlUbFDpRp0fTPECvPfAA= Received: from imx12-a.toshiba.co.jp (imx12-a.toshiba.co.jp [61.202.160.135]) by relay.securemx.jp (mx-mr1110) id 1911EIcq016022 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 1 Oct 2021 10:14:20 +0900 Received: from enc02.toshiba.co.jp (enc02.toshiba.co.jp [61.202.160.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by imx12-a.toshiba.co.jp (Postfix) with ESMTPS id CAFD2100110; Fri, 1 Oct 2021 10:14:18 +0900 (JST) Received: from hop101.toshiba.co.jp ([133.199.85.107]) by enc02.toshiba.co.jp with ESMTP id 1911EI3s029015; Fri, 1 Oct 2021 10:14:18 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hYw9ZqR+n4kopMZY9H1mlmmFyrblGx2+gZlVIAGX84+l8Wxn9okUtSqaiTcJWWFkTHvdDZqoLAiFZ16ZLaZlgnysxOJgMdNtfzUfds0e1vac5I47J7J9tl8BnFGzUtgZxtZBKyM45Goqaxryo/rxaxbc2P94YqGCiVZsRePxVtb3SnXEvtjT+t+6bX1gHb+KK26a44UDqAUHUu+DI26xTar06E/OWfAUtoh9J2FmlJsi38ZpuOkNOI57tsyw6f8M24E29gBqtCRpzJKSSkLpwGL8Y6WjAke5iFVYTRg8kypYILrD3JRFQcXE41flfPSylIYNSRyTqyFokt3MBwjSJQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=D1VRYsGfGxcQ5YPDs/NqaDcDxw2RbJd7Zrhh3lTFHXg=; b=IFzzJte0VF6Gyaw7eJdwk6lB/RVU4nGJSLfy8DHM00+6KfMfeLf0x4EmUIId5/bDPGOkVA6jgyX4mz3cdgTQxlSErHpsJbXIT34dxXChnDm35+gSCDtkPWdRTKOQF2bGVj+wZc0qxtST2qzCQgaVxxOg1hmbmlngJvFPz+INge21txBU5rCp6JSf32RB9tGbyq+Yw8RMVyS1MO0+ZX0xyjkaR2vF/TOU0ZGsQq7VdbLbMXAdzFPQeivkaBN7yG/3gMahI0FQZJ2EpbimGFrZCi2XfxeF0ukUFVtuKF5qVtAfgxMGJiM0HT0IA+eOK+6xM2VuC0RnR5toTysVw0Dn1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none From: To: , CC: Thread-Topic: [OAUTH-WG] self-issued access tokens Thread-Index: Ade01Nk+d5eF4L5tTXCgjU67TgIDjwAc7pmAAB+fWwAAJootgA== Date: Fri, 1 Oct 2021 01:13:57 +0000 X-TSB-HOP: ON Message-ID: References: <581ea93b-ab52-e4e2-ec53-c776060e99d1@danielfett.de> <09C675DC-1DC8-4860-A4DD-CE70B1FD5577@aueb.gr> In-Reply-To: <09C675DC-1DC8-4860-A4DD-CE70B1FD5577@aueb.gr> Accept-Language: ja-JP, en-US Content-Language: ja-JP authentication-results: aueb.gr; dkim=none (message not signed) header.d=none;aueb.gr; dmarc=none action=none header.from=toshiba.co.jp; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa594c9e-bf9a-4b79-b0a5-08d98478be44 x-ms-traffictypediagnostic: TYAPR01MB3997: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fk0n+Cj6bf71FjtuGRMpAQfiNRyNineBdPx9A6gypUkImLJ9k3dOnQi/TpcLTsVifG3nBYVW8NmDnvCiZv2joeqv8LxYstVCpqhkLOmA1hYHyvKLTonngUxvHNU+o4wx2Jd6Ka34vsTTOGdseSfxxCA+2z9CtzmgWaXmrcbCBnohNjk4NIRSLt3URnsKiHthaWtmEim05e5cS2bsa0jFRkRS18mXEx7vgL/uhGD4wTrr2YJswRtYhv9vAep8Jm4zB/KdL0RGIijzDk6CefMJEaHKuqqV/IDpFo82AqwIR/cSTJ6PZbwI5N0pNvr6+1MCBOS75ULGswYgjenFcBB3wSstE0w+f+GviDJGeFzwg6guOByvUMQA/dg4JSa/oGvTO5KJCHBpogDCsiVQR8EhNcb4I40LSYG75q7EeZn8glEuCy6Nc4FKJzcJUAkq1bDvBrAr72BqS+FTm9L4TTUWjsudCNvWUDSwoHoLOoTqMqpLtdPzyZcylTbrZjOhoUC/pw8JrBmSvwt3bRf9vDPayx4j0uKoGLbgnyIeQab33j3A2aPfKq6bcY5BSdnhiAPpMXIgkwwn6rumAF/d+zGTZuRp2g1GxNI9DPDOxKLfy0ZkWK1vBbtzhfmQeUWSMdg1INgo/VzP3KOfgccNkkxeeo9j3Q5GreE0bV2by2akSebkt5G1vFXfYvwT4CgogyX3O89BBswZKPDU1TxK7fvb9KYz+XHf2Xle0hlhUy5ZOa7FprQRDf5fZIK8cvfcKg57XJI8kiTrsuHILCDfQ3EqJH2HQRbh5F0Jcaw0UtzGgwU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYCPR01MB5678.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(52536014)(26005)(508600001)(64756008)(966005)(66556008)(4326008)(71200400001)(33656002)(186003)(122000001)(38100700002)(316002)(55016002)(9686003)(5660300002)(110136005)(66946007)(66476007)(66446008)(2906002)(53546011)(38070700005)(83380400001)(8936002)(7696005)(86362001)(76116006)(6506007)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?L0d3YWp3cVY1OEpmelhlV01OcVZmdnRGQkk3cVNia3NEN1BEalZHcGYy?= =?iso-2022-jp?B?b2k0cndMMG5ZR3FHK1Z4elBMVW0wT1MyUlMzaFozYmhkcVdaS3BLbDMr?= =?iso-2022-jp?B?OU9FaVA3RWJvSURzbzc1V1N1Y05nYkViZGpSSHM0N2MwNkpBcENxTXU3?= =?iso-2022-jp?B?aFpzaERwWnhaSVNRU2QwV1ZYa1lySnlPUXhGYnlvK0hLYVUzbEIreElv?= =?iso-2022-jp?B?OWl1RUF6eGduMjJJT1VieDhRWE53dFoxUEgxeEtiY1RxR0F2TldKMUJI?= =?iso-2022-jp?B?SlJuV1oxV0lodjFsRURrUDhtbFBrQ2VMMXArb2s0cnlIN0lLbEFwdERS?= =?iso-2022-jp?B?eUJ6Q2lqVVhweWZrOU9YTllOdzk2KzdlemZLN2Z4MEpBdnB1MlNYNStG?= =?iso-2022-jp?B?Mkg0TFkxUHBzZ084SC9QajlWZlRJaTlubkhyOTQ2RjFxWXdrUzJQVFNt?= =?iso-2022-jp?B?K3NnQi9EU0xwR2d1dGRjRklmNDNEekxWbEF6bU1NTVFrM1VFYlcwMzFx?= =?iso-2022-jp?B?MlpLd3kwZ29zOVQ0MnhhZXdPODFtNlY5NnNycmVqUkhXWEdqVUY0Mm9O?= =?iso-2022-jp?B?ZmluUHplYTJiSys0citIdFNsOFo0ZTR2RjNsRnNkTFNQRU5yaHVvU0Uy?= =?iso-2022-jp?B?T0o5MzNaSDl0Z1lscGtOdVhCS09ncWNGZFNJL1NtZkgzRGJUazJYc1Iz?= =?iso-2022-jp?B?RDZFSWNFamdvT1c4ZnZtd1M3Y1poZ3dTbHNiSUlLbHhZZEk2QVZrSzI3?= =?iso-2022-jp?B?WmZFYmh3aVpCT1RERTF3Nm9HZE45OW0vRm5Ma0tNcGlaM1Q0SmdSSUU2?= =?iso-2022-jp?B?WXl3V29ZdEVHekxnd0VkeXF3Qm5oNTk4QkhVNy9yR0RhU0xpUUkzUkF1?= =?iso-2022-jp?B?Y3ZYS2ZFSStYNzZGV3ltN0F5RXFROVJGY0ZrUUdYT1NiZ2RtTE9IbFdD?= =?iso-2022-jp?B?UXRnV2JnbFl1ZVVRVFczVXlLdVUrZ1hsenJjcnhZaVFzKzVxdVlOeUw2?= =?iso-2022-jp?B?NkQzaUxYZHJxS2hJNkZ2TUQyKzNkNE1VdGV1WWgzWGdPMUNKSDlaQ1Fm?= =?iso-2022-jp?B?SExQNUd2R1pnVjdLUWxMMnpQd1BsMHBSSWNrZ2pCWlZXVS8rMXlIbXZm?= =?iso-2022-jp?B?b3hVQTN4cWNDUkx2aVBCTW5LazY1S2hrQ3RYK05WSEl3S3c4VGpnT1Vx?= =?iso-2022-jp?B?NFdYWG05TG4wQmZ0TDMvNWVBanR1eDNtOC9TVnN2SmRFQXpMTlZ4U1hy?= =?iso-2022-jp?B?VmpXb1lLS3JJM2RhMjJHdmFGdGcrL3BKdjVkcHc0NE1tSE5KRjBVQTBl?= =?iso-2022-jp?B?aVhwWGxvVkprbFFZa0J0K0lCNEhrZHdudyt3REgyMGRDOXlXQjFad2NC?= =?iso-2022-jp?B?d010OUxJdkZndFNlNmJWUXNZODhOaHFDQVM0K2tXR1NzbHRXVXAvRnBV?= =?iso-2022-jp?B?WXJ2cDQzN3cycDhudkZpeFdnYkRlUEk3R2h1aE51empnb3Q3UWQrVFBr?= =?iso-2022-jp?B?RDQ4NG9qaFJvd1pPLzRtOHd1RElJUVJORXpVMFdrT3FhK2h2Z3NRWDVN?= =?iso-2022-jp?B?OUI3dmUvQncxN2ZrTWlBQStnKzhST0NmT0hIVHpKM2ZHTGRtMmlEMkhJ?= =?iso-2022-jp?B?WGUyR3dYSXFvU1BzZys3bnNaMkRqSlA2cnY0RVFyQzRpKzd1WVRWTmt1?= =?iso-2022-jp?B?NGhhemU4N1kyY0s4aTNlTkpnRTlFRXdFSWp5MWJkZFhDdG9KcGFvK0FN?= =?iso-2022-jp?B?M2Jla2dNOVlubHljMEVPK3ZaNHVyMlgveG9lN1BLRTRORHpYWm84RVFY?= =?iso-2022-jp?B?dDZvNlRVZFVQK2pKNUl2VjNHd2JGSmRWMlpHMmVqNWprdFArK0hQRjlr?= =?iso-2022-jp?B?dkd6WEVIMXRMZUJIL0VvbUNrQWpnPQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYCPR01MB5678.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa594c9e-bf9a-4b79-b0a5-08d98478be44 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 01:13:57.1645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dah2ObNQ1bqOqJ8rrurqj9Ns6co7yq/A9agHk8K79TpIsxJXx+NwGXHsZoRykQ8xE2Ljh0NV5gNJqMI8olmm1+Gx5c4j++PYnoBHfnyd9tI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3997 X-OriginatorOrg: toshiba.co.jp MSSCP.TransferMailToMossAgent: 103 Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 01 Oct 2021 01:14:59 -0000 Thanks Nikos, It sounds interesting to use Verifiable Credentials in this scenario. I'll = read the paper. Toshio Ito -----Original Message----- From: OAuth On Behalf Of Nikos Fotiou Sent: Thursday, September 30, 2021 3:48 PM To: Daniel Fett Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] self-issued access tokens FYI, this is exactly what we are doing in [1] to manage Verifiable Credenti= als using OAuth2.0. The AS issues a verifiable credential that stays (for l= ong time) in the client. The client uses DPoP to prove ownership of the cre= dential. We just started a new project funded by essif [2] that will furthe= r develop this idea and provide implementations. Best, Nikos [1] N. Fotiou, V.A. Siris, G.C. Polyzos, "Capability-based access control f= or multi-tenant systems using Oauth 2.0 and Verifiable Credentials," Proc. = 30th International Conference on Computer Communications and Networks (ICCC= N), Athens, Greece, July 2021 (https://mm.aueb.gr/publications/0a8b37c5-c81= 4-4056-88a7-19556221728c.pdf) [2]https://essif-lab.eu -- Nikos Fotiou - http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimed= ia Laboratory Athens University of Economics and Business https://mm.aueb.g= r > On 29 Sep 2021, at 6:42 PM, Daniel Fett wrote: >=20 > That very much sounds like a static string as the access token plus DPoP. >=20 > -Daniel >=20 > Am 29.09.21 um 03:54 schrieb toshio9.ito@toshiba.co.jp: >> Hi OAuth folks, >>=20 >> I have a question. Is there (or was there) any standardizing effort=20 >> for "self-issued access tokens"? >>=20 >> Self-issued access tokens are mentioned in a blog post by P.=20 >> Siriwardena in 2014 [*1]. It's an Access Token issued by the Client and = sent to the Resource Server. >> The token is basically a signed document (e.g. JWT) by the private=20 >> key of the Client. The Resource Server verifies the token with the=20 >> public key, which is provisioned in the RS in advance. >>=20 >> I think self-issued access tokens are handy replacement for Client=20 >> Credentials Grant flow in simple deployments, where it's not so=20 >> necessary to separate AS and RS. In fact, Google supports this type=20 >> of authentication for some services [*2][*3]. I'm wondering if there=20 >> are any other services supporting self-signed access tokens. >>=20 >> Any comments are welcome. >>=20 >> [*1]:=20 >> https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-acce >> ss-tokens/ >>=20 >> [*2]:=20 >> https://developers.google.com/identity/protocols/oauth2/service-accou >> nt#jwt-auth >>=20 >> [*3]:=20 >> https://google.aip.dev/auth/4111 >>=20 >>=20 >> ------------- >> Toshio Ito >> Research and Development Center >> Toshiba Corporation >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > -- >=20 > https://danielfett.de > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Sep 30 20:53:10 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10863A005E for ; Thu, 30 Sep 2021 20:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 QPxoEVaYlmkw for ; Thu, 30 Sep 2021 20:53:03 -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 B2BE43A003C for ; Thu, 30 Sep 2021 20:53:02 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id g41so33326691lfv.1 for ; Thu, 30 Sep 2021 20:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UTI3tZ3McX82gtOGgbcPSLIk4j3rFDNvNNi98DYC6Rk=; b=MTTcyExjXfcD08Pm3RJTRgZd4ycXQp/Cizvk1mVx/kgDbK434QbEwfaFY/pwXqbJKd YiUlAU9Wj9COPnh6EFoK68DK0HWb9oroowbhQEG0fKCfAFNEi415yxUU51+DHU8UbHlu gjXSOmK0xatnOVK0DDqZbnyfp6rdaB02Q6wmIDCRdGPVlbmVIhE23Ea61Z5+LDFnzdLG xVGTV43Fd10Jn+9dJAZ/G1FJhGFwW7vUgPLkwUhVWBkpMxjmRhF3oeX6BwH4VWdgFRT0 HiIEsgIHSb5PC5IU271qN8xm9LYTdTM5t3hJmYoyfVbBuT/8wUYNR9a31coNnouXwcyr zmGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UTI3tZ3McX82gtOGgbcPSLIk4j3rFDNvNNi98DYC6Rk=; b=oKFbDTQCiv3l3B4SSJ/8FNfYeVGq7/Kb8aLbcK4PZGJwspP4Zi+3NXJH0OyM3z+rSI rsV53Ij3BDV2IaxIYoCy6J7rED/WzfI5Vw1jlzJucY4ibmY85b25dTBRH2tF0lFSKmic 9XNUKiQ15+jGw2UtPqV09v3H0Jwy+jKl44wwsoek+jNZDM4Adb71nS0s+hQ+IJjd+6Ri jrq4Cj5HbiG9R7LS/DHVSj96YOlbUHJbNY1RsoY5OMAnddahT8HpFGH1ciT5x9bn/K6d hcYZfEPmE1Glp6YmDLWxXGSWld6r9u+sypQhUIhdiUBU8R8+5o2mVqw6qlVkPGs+4Ufw vR+w== X-Gm-Message-State: AOAM531QLef/DxSPyJ9AUlNEHXJD7BPXPvg1bDQXIBPk5HtJzQg0OHvF 2zyMBmVhUj43PjQW1sk5ZRXwnNGlT131AKdhfG0= X-Google-Smtp-Source: ABdhPJxahWunrOXxnGAifzdIVKzSNMaNR+K3F4wCAjYT7i+k20aDfJ/44pFNbJt5JXiFi1OP1rNzXdY9lGjR/b7tElc= X-Received: by 2002:a05:6512:3091:: with SMTP id z17mr3035019lfd.246.1633060380128; Thu, 30 Sep 2021 20:53:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Thu, 30 Sep 2021 20:52:49 -0700 Message-ID: To: toshio9.ito@toshiba.co.jp Cc: oauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000dab87b05cd427fe8" Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 01 Oct 2021 03:53:08 -0000 --000000000000dab87b05cd427fe8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Would be useful to understand your use case and what you the goals and constraints are On Thu, Sep 30, 2021 at 5:58 PM wrote: > Thanks Dick, > > > > I agree. The scenario of self-issued access tokens doesn't really follow > the > > model of OAuth. > > > > So, if we do standardize self-issued access tokens, maybe OAUTH WG is not > the > > right venue. Maybe HTTPBIS or HTTPAPI WGs? > > > > > > Toshio Ito > > > > *From:* Dick Hardt > *Sent:* Wednesday, September 29, 2021 3:06 PM > *To:* ito toshio(=E4=BC=8A=E8=97=A4 =E4=BF=8A=E5=A4=AB =E2=97=8B=EF=BC=B2= =EF=BC=A4=EF=BC=A3=E2=96=A1=EF=BC=A9=EF=BC=B4=E7=A0=94=E2=97=8B=EF=BC=A3=EF= =BC=AE=EF=BC=AC) > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] self-issued access tokens > > > > If the client is sending a self-signed JWT to the RS, you essentially are > just authenticating directly to the RS. Not really OAuth as the RS has no= t > delegated authorization authority to the AS. > > > > If the client sends a self-signed JWT (a PAR) to the AS, and gets back an > access token to present to the RS, you get centralized authorization > decisions, a key feature of OAuth. > > > > > > > --000000000000dab87b05cd427fe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would be useful to understand your use case and what you = the goals and constraints are=C2=A0

On Thu, Sep 30, 2021 at 5:58 PM <= ;toshio9.ito@toshiba.co.jp= > wrote:

Thanks Dick,

=C2=A0

I agree. The scenario of self-issued access tokens doesn't rea= lly follow the

model of OAuth.

=C2=A0

So, if we do standardize self-issued access tokens, maybe OAUTH WG= is not the

right venue. Maybe HTTPBIS or HTTPAPI WGs?

=C2=A0

=C2=A0

Toshio Ito

=C2=A0

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Wednesday, September = 29, 2021 3:06 PM
To: ito toshio(=E4=BC=8A=E8=97=A4 =E4=BF=8A=E5=A4=AB =E2=97= =8B=EF=BC=B2=EF=BC=A4=EF=BC=A3= =E2=96=A1=EF=BC=A9=EF=BC=B4=E7=A0= =94=E2=97=8B=EF=BC=A3=EF=BC= =AE=EF=BC=AC) <toshio9.ito@toshiba.co.jp>
Cc: oauth= @ietf.org
Subject: Re: [OAUTH-WG] sel= f-issued access tokens

=C2=A0

If the client is sending a self= -signed JWT to the RS, you essentially are just authenticating directly to = the RS. Not really OAuth as the RS has not delegated authorization authorit= y to the AS.=C2=A0

=C2=A0

If the client sends a self-sign= ed JWT (a PAR) to the AS, and gets back an access token to present to the R= S, you get centralized authorization decisions, a key feature of OAuth.<= /u>

=C2=A0

=C2=A0

=C2=A0

--000000000000dab87b05cd427fe8-- From nobody Thu Sep 30 21:45:19 2021 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C04E3A0400 for ; Thu, 30 Sep 2021 21:45:14 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 z_C1m8z9ycZQ for ; Thu, 30 Sep 2021 21:45:08 -0700 (PDT) Received: from mo-csw.securemx.jp (mo-csw1116.securemx.jp [210.130.202.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3553A0402 for ; Thu, 30 Sep 2021 21:45:07 -0700 (PDT) Received: by mo-csw.securemx.jp (mx-mo-csw1116) id 1914j3pI020504; Fri, 1 Oct 2021 13:45:03 +0900 X-Iguazu-Qid: 2wHH6p2Z6cmIfVLIXO X-Iguazu-QSIG: v=2; s=0; t=1633063503; q=2wHH6p2Z6cmIfVLIXO; m=q1EmHmzEbzFdppHs2pGv2Hv/thTpsOVRHAYjzSnTPpQ= Received: from imx2-a.toshiba.co.jp (imx2-a.toshiba.co.jp [106.186.93.35]) by relay.securemx.jp (mx-mr1112) id 1914j2do028548 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 1 Oct 2021 13:45:03 +0900 Received: from enc01.toshiba.co.jp (enc01.toshiba.co.jp [106.186.93.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by imx2-a.toshiba.co.jp (Postfix) with ESMTPS id B771F100112; Fri, 1 Oct 2021 13:45:02 +0900 (JST) Received: from hop001.toshiba.co.jp ([133.199.164.63]) by enc01.toshiba.co.jp with ESMTP id 1914j2ZY031465; Fri, 1 Oct 2021 13:45:02 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XwiiQVda2g+8aZPNqsd83lzIBMHbamzOOyyo3PCGDsiz4OScyFv9hcA8z6S/aynmtl/JQ0kgAn3wh4Po2wj4XH+mBVWFYv1bLEOn1xdyNnXkaPhTkWeAcyz0KHVxatbSnq/HOBlIHM9lVbPSyyOW1reEVfQVuX5LN4RcVZ0r0dS4I494U5XH5m8gY4iIQS+fk4faqtJ0/2qGSRdTmyqPuj/0owOarztSQcH8FVmrYdg86B5JG7vQt+Gk5xWBVVHehjaDDuRKrGcz/rAs2a+hoyLyl2Igc2oWc8UowFLvp74wEIC1RUx5gCKJEX2YNgTYWnp745lXtjJFKhl+2LGx+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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rAJlCBWhVPGGoF9MfF0VMnz1URxQ18Sy19ihx/ZKRyg=; b=GGmMTbvSMqQJmksVOyEkKNv8hQEgqwLxzMnbUJlbe22HOCBhVbrli/ASIFWFrG6Wn8llKWh9ZYZE1BEVjZGfe+prUZ772xR+0s8kfS3N/Kk1GJiGkvwWC3pRjSgh29PM/Nl2TPEM6Vfjvg1JNdLUU+NUJqm1OWIAQLlDNccxZT6TaeOar7O8/ZF/JWF9KfGfj8QXTpHGd/JW8MuUb32yeE+R+FzVUHXrgGVuMwhxidndfJ1t6SZ2lCrGn3/2PpejCEWSkV6moHC35SdakGpKNB4BER612It86CqI5mdfJ+o/uOvKWNLtXsckXM/zAiMU6bu+O/tC3kwTBb8iu9zlvg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=toshiba.co.jp; dmarc=pass action=none header.from=toshiba.co.jp; dkim=pass header.d=toshiba.co.jp; arc=none From: To: CC: Thread-Topic: [OAUTH-WG] self-issued access tokens Thread-Index: Ade01Nk+d5eF4L5tTXCgjU67TgIDjwAIzLwAAFmdA8AABlM7gAABzSyA Date: Fri, 1 Oct 2021 04:45:00 +0000 X-TSB-HOP: ON Message-ID: References: In-Reply-To: Accept-Language: ja-JP, en-US Content-Language: ja-JP authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=toshiba.co.jp; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd5bbea5-352d-4f7c-2c85-08d984963a36 x-ms-traffictypediagnostic: TYAPR01MB5337: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HEIgPY15saQr5nEdGJkQz27Da6ruiFMXvPE/H4wVtTRWQIPDxQsGENIVYtQxoR57Ue4SNMY7pLF2lawEZwboBSniieHGO/Ny1+rMvvvt5vfTGwdRdSkaHTaDNf/8HZTf0jwX8piB7sloPJJtgAxdBl8Q4pvcYbU0SIwCIikKVOJUqHDgw2kBQLhor4QnqBLAmEAuL1sh3dcE9QrOAT6qzHT1ahQFSjzPct3a4ebP1dEbBWj3A/nrrAhB6wR3Aa6DX/GJ2xuFAefpxPRtk7jKZSZfOmdQQZXc9KwOCX2wbIPAliko/14LhA8wjtcQhM50/xHcLbMqwTJvTfqXdlr4P/+Wfuc6o1gRR/mHTKH0/Uu3uSo7Q7Zivlv1uePcqKbNYWVtjZwrpeR/qcZCFBAfZhJ3qBuBsBvnwdbuheD0AW1kjEVeLeoOmXGoZC5SXWRctcWSIv3V7DDu0Vo7Xi7n+ScAxAhRjru5DTsJ+Ryfx0vftTsKmh4RBoJ2LB6hyRixACVzPUaAtbiMwTtAA6ODY1ER2eopnWP+80dp8Ig06J+04y+XJqkiajcCt4RJLsV6bEKxQFoI3+bl3lirOBXly9QC+SHCQ6sT2bo1cof6Y+wxjUZSd/Nw1puayQnaYyELZWcQLm+6vTICv63aBTtBiKWTOf0DZY3iDps+bMEctFFlij2l+DTsNonGtE5UPIyTrhqaJDIcoMuu6upRAqlEKg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYCPR01MB5678.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(7696005)(186003)(8936002)(86362001)(26005)(38100700002)(66446008)(64756008)(6506007)(316002)(4326008)(53546011)(508600001)(33656002)(5660300002)(83380400001)(8676002)(66946007)(66476007)(122000001)(9686003)(66556008)(55016002)(2906002)(71200400001)(6916009)(52536014)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TE14eWRTekdHeFVOU0w1S0dnZVNENlhGQTQ2MG9tdGliclNpTGdxQ1ZVVTZo?= =?utf-8?B?WGtlZ21weDVOamx2cGdFRlp3WjR4NmJMMDJmTm9jd25WWTE1OHh5cFVHZGFZ?= =?utf-8?B?d3VnMVhJV0tQYnJQc1dsS1NFUm55Tkdka2hXOG95M0ZRWjQwN0F6S2kwby9J?= =?utf-8?B?ZHRjbktVOU9IVjVyZ3lkSURhVDNxeDl3TkZHbzBFbFZYTTVjSlp2MU5lbnIy?= =?utf-8?B?MFJFejA5VzR4MDRBMzFoaU1LWmZrRnZMZS9JZWlKSGVBa1RtVjRNVWpqUjJm?= =?utf-8?B?eEZhYjMwQmR5Uk5FRlptUTZENjZlUVkvcityeE5qeFk4QkZTcFdhcDBBdEpJ?= =?utf-8?B?QzN2cUs2RWtwR0ZQRDR6OVl4ZUxReEJZaVl0K2xYc0haMFdSOWlvc1pqUk9t?= =?utf-8?B?OUhLbit6cndKSHBIcFNIQkM4UGxGeWVnbW02SUxuUkxGbTdMRVRtVUV2SDNS?= =?utf-8?B?ZEtXaFBsT2QwcmdrV1JjdFA5MDBKK3o3OWdud2RJYzkzY1pXcjUvYmt3bVRO?= =?utf-8?B?b1FPT1ROQk40cjFYWngxRlluN3JQY0pkZzc2L2RYYjYvK2dnVTR5ZHp4REVI?= =?utf-8?B?a2pCVVZVZXVIcHJDRmJMWUZadTRFUkhtYkRESVVmejBEc1QremlaU0xwVjVm?= =?utf-8?B?a2paUXZpdW5YQjNiTncwblN3NHdNdjF4R0JMd1lXNVFXbWN4STJuQ0syK1Rh?= =?utf-8?B?eHl0dVI0NHBCSEFQamEvbkhJejdsekgzZ2dPR0R4aHlxS2xIendvOC9QcG5l?= =?utf-8?B?SURUSHZWajhQdHhmdkNZVzV1WDhBKzNXNG9WeWxXTjkzRHNRZmV3eGY2R2ZR?= =?utf-8?B?RFFKckc2Z2JEclk1VUVsaXZrWEhneVVROE0zQWNVc1gxcDR5dGRGN2VCbjBj?= =?utf-8?B?UzNGZEpSMUwwYTRiY2V2c0I3cDVsUkpmUTJLamQrUjVjcXFsNUFCaTJmWDE5?= =?utf-8?B?TnN2LytMMmtYeG9hNC9HajNmOUlkZGpvU0hxcm4yN3YyWEpkVkM1REJWVVBl?= =?utf-8?B?cXBXTmFvb1pxMU5sRUpuSzlrQTM1YkJuNU0wQTVUMTRwSWhFVy9rRUFPdUpF?= =?utf-8?B?bnFHUC92SFRwK3VFTnRndUxoMmQvdlZwdWg3K3hqYkxTcldBQlQ1MWIyV2FD?= =?utf-8?B?TytQa2ZPZTVOM0RkcnlWaVJ3Z0FNa1ZHSVNjNlBTMTBDZEJRamwvU3RsbVpK?= =?utf-8?B?YjVmTDMvOC9vWlBzeE5ad3FFcEtMZGVydGJaUTMyaHF1SUxPc3BYdWt3U0p5?= =?utf-8?B?VWtaQk9wRkNXL3ZTczlOYVFmbGtCU1hsUU9NdUIxRDJydU0rdEJlUEdsQllB?= =?utf-8?B?ZWxJM0hXT0UxZEZXNTV0cWZsd3phTW9rbktVeXo4bzJ5MFZPb1hLUjFCc3V2?= =?utf-8?B?RTFDdndGckpGV3ZOaXJjVEpRMlNIaDV4Sy8yUU84TTF1eDhJSEJtTnR0U0Jt?= =?utf-8?B?UWRNcUhKUGVkWUp5Y1M5RHpkRkdwelF1OUtjMENpaGhwTktDTXE1UG1ieE1M?= =?utf-8?B?MzY1TklOeGwwVXhOWFprcGF6UVVWUUsvTFNqcEUwT1M3Yk45d1pmQ3pxRHdi?= =?utf-8?B?emFwUW55ejk2Zm1jRWo2Vi9XVGRFcUNjeHNleXh4bUN0UmdaV29HbHVPL3h1?= =?utf-8?B?Kyt3VjJuTjJjWXhmOWVadXk2VkU2Nmt3MzVlZGEzU2Y4YnlPd1FocnV6akxL?= =?utf-8?B?bzVXVE1kY2FrSStieTJrWHFBUFBBZmNXcXgwcFJnUjhYNi9LQ2pvaUZUTFVY?= =?utf-8?Q?0QQyUuV03EndbmNOu0kk9byCrb+H85JZmTvF5n7?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_TYCPR01MB56787D963D23F78B0800C6CBE5AB9TYCPR01MB5678jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: TYCPR01MB5678.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd5bbea5-352d-4f7c-2c85-08d984963a36 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 04:45:00.5777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OasvZuoKUjAa8h5tRn3Qro8GTzWkWgjpBTz1gLSQGYJtwAymNAVAPBU1QVwnOGrX+OGhO8ZtxapY1v2wxVBoaJmiMq+eZTxxlCI+h3z9Ii0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5337 MSSCP.TransferMailToMossAgent: 103 X-OriginatorOrg: toshiba.co.jp Archived-At: Subject: Re: [OAUTH-WG] self-issued access 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, 01 Oct 2021 04:45:15 -0000 --_000_TYCPR01MB56787D963D23F78B0800C6CBE5AB9TYCPR01MB5678jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIERpY2ssDQoNCk91ciB1c2UgY2FzZSBpcyB0byBjb25uZWN0IElvVCBkZXZpY2VzIHRv IGEgY2xvdWQgc2VydmljZS4gVGhlIGNsb3VkIHNlcnZpY2UgaGFzDQp0byBhdXRoZW50aWNhdGUg dGhvc2UgZGV2aWNlcy4gVGhlIGRldmljZXMgYXJlIG5vdCBvcGVyYXRlZCBieSBodW1hbnMuIFRo ZXkgcnVuDQpvbiBpdHMgb3duLg0KDQpXZSB3YW50IHB1YmxpYyBrZXktYmFzZWQgYXV0aGVudGlj YXRpb24gZm9yIHRob3NlIGRldmljZXMuIEluIHRoYXQgY2FzZSwgbXV0dWFsDQpUTFMgaXMgYSBw b3B1bGFyIG9wdGlvbiAoZS5nLiBBV1MgSW9UIENvcmUpLiBIb3dldmVyLCB3ZSBkb24ndCB3YW50 IHRvIHVzZQ0KbXV0dWFsIFRMUyBmb3Igc2V2ZXJhbCByZWFzb25zIChlLmcuIGl0J3MgdG9vIGNv dXBsZWQgd2l0aCB0aGUgdHJhbnNwb3J0IGxheWVyKS4NClNvLCB3ZSBhcmUgc2Vla2luZyBhIHNv bHV0aW9uIHRoYXQgaXMgbW9yZSBpbiBhcHBsaWNhdGlvbiBsYXllci4NCg0KDQpUb3NoaW8gSXRv DQoNCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPg0KU2VudDogRnJpZGF5 LCBPY3RvYmVyIDEsIDIwMjEgMTI6NTMgUE0NClRvOiBpdG8gdG9zaGlvKOS8iuiXpCDkv4rlpKsg 4peL77yy77yk77yj4pah77yp77y056CU4peL77yj77yu77ysKSA8dG9zaGlvOS5pdG9AdG9zaGli YS5jby5qcD4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gc2Vs Zi1pc3N1ZWQgYWNjZXNzIHRva2Vucw0KDQpXb3VsZCBiZSB1c2VmdWwgdG8gdW5kZXJzdGFuZCB5 b3VyIHVzZSBjYXNlIGFuZCB3aGF0IHlvdSB0aGUgZ29hbHMgYW5kIGNvbnN0cmFpbnRzIGFyZQ0K DQpPbiBUaHUsIFNlcCAzMCwgMjAyMSBhdCA1OjU4IFBNIDx0b3NoaW85Lml0b0B0b3NoaWJhLmNv LmpwPG1haWx0bzp0b3NoaW85Lml0b0B0b3NoaWJhLmNvLmpwPj4gd3JvdGU6DQpUaGFua3MgRGlj aywNCg0KSSBhZ3JlZS4gVGhlIHNjZW5hcmlvIG9mIHNlbGYtaXNzdWVkIGFjY2VzcyB0b2tlbnMg ZG9lc24ndCByZWFsbHkgZm9sbG93IHRoZQ0KbW9kZWwgb2YgT0F1dGguDQoNClNvLCBpZiB3ZSBk byBzdGFuZGFyZGl6ZSBzZWxmLWlzc3VlZCBhY2Nlc3MgdG9rZW5zLCBtYXliZSBPQVVUSCBXRyBp cyBub3QgdGhlDQpyaWdodCB2ZW51ZS4gTWF5YmUgSFRUUEJJUyBvciBIVFRQQVBJIFdHcz8NCg0K DQpUb3NoaW8gSXRvDQoNCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1h aWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAy OSwgMjAyMSAzOjA2IFBNDQpUbzogaXRvIHRvc2hpbyjkvIrol6Qg5L+K5aSrIOKXi++8su+8pO+8 o+KWoe+8qe+8tOeglOKXi++8o++8ru+8rCkgPHRvc2hpbzkuaXRvQHRvc2hpYmEuY28uanA8bWFp bHRvOnRvc2hpbzkuaXRvQHRvc2hpYmEuY28uanA+Pg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0 bzpvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHNlbGYtaXNzdWVkIGFj Y2VzcyB0b2tlbnMNCg0KSWYgdGhlIGNsaWVudCBpcyBzZW5kaW5nIGEgc2VsZi1zaWduZWQgSldU IHRvIHRoZSBSUywgeW91IGVzc2VudGlhbGx5IGFyZSBqdXN0IGF1dGhlbnRpY2F0aW5nIGRpcmVj dGx5IHRvIHRoZSBSUy4gTm90IHJlYWxseSBPQXV0aCBhcyB0aGUgUlMgaGFzIG5vdCBkZWxlZ2F0 ZWQgYXV0aG9yaXphdGlvbiBhdXRob3JpdHkgdG8gdGhlIEFTLg0KDQpJZiB0aGUgY2xpZW50IHNl bmRzIGEgc2VsZi1zaWduZWQgSldUIChhIFBBUikgdG8gdGhlIEFTLCBhbmQgZ2V0cyBiYWNrIGFu IGFjY2VzcyB0b2tlbiB0byBwcmVzZW50IHRvIHRoZSBSUywgeW91IGdldCBjZW50cmFsaXplZCBh dXRob3JpemF0aW9uIGRlY2lzaW9ucywgYSBrZXkgZmVhdHVyZSBvZiBPQXV0aC4NCg0KDQoNCg== --_000_TYCPR01MB56787D963D23F78B0800C6CBE5AB9TYCPR01MB5678jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg 44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi77yt77yzIO+8sOOCtOOCt+OD g+OCryI7DQoJcGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiw78yZMO/MzMgIDBiNDBiNzBjMzBhZiI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3Nl LTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDv vK3vvLMg44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8re+8syDvvLDjgrTjgrfjg4Pjgq8iO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk644Oh44Kk44Oq44KqOw0KCXBhbm9zZS0xOjIgMTEgNiA0 IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA44Oh44Kk44Oq44Kq Ijt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MG1tOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBtbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjt9DQpzcGFuLjE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiLvvK3vvLMg44K044K344OD 44KvIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5Oua4uOOCtOOCt+ODg+OCrzt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjk5LjI1cHQgMzAuMG1t IDMwLjBtbSAzMC4wbW07fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiI+DQo8djp0ZXh0Ym94IGluc2V0PSI1Ljg1cHQsLjdw dCw1Ljg1cHQsLjdwdCIgLz4NCjwvbzpzaGFwZWRlZmF1bHRzPjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJKQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIERpY2ss PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDj grTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7 Y29sb3I6IzFGNDk3RCI+T3VyIHVzZSBjYXNlIGlzIHRvIGNvbm5lY3QgSW9UIGRldmljZXMgdG8g YSBjbG91ZCBzZXJ2aWNlLiBUaGUgY2xvdWQgc2VydmljZSBoYXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztj b2xvcjojMUY0OTdEIj50byBhdXRoZW50aWNhdGUgdGhvc2UgZGV2aWNlcy4gVGhlIGRldmljZXMg YXJlIG5vdCBvcGVyYXRlZCBieSBodW1hbnMuIFRoZXkgcnVuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29s b3I6IzFGNDk3RCI+b24gaXRzIG93bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt 77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSB3YW50IHB1YmxpYyBrZXkt YmFzZWQgYXV0aGVudGljYXRpb24gZm9yIHRob3NlIGRldmljZXMuIEluIHRoYXQgY2FzZSwgbXV0 dWFsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8 syDjgrTjgrfjg4Pjgq8mcXVvdDs7Y29sb3I6IzFGNDk3RCI+VExTIGlzIGEgcG9wdWxhciBvcHRp b24gKGUuZy4gQVdTIElvVCBDb3JlKS4gSG93ZXZlciwgd2UgZG9uJ3Qgd2FudCB0byB1c2U8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOC t+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdEIj5tdXR1YWwgVExTIGZvciBzZXZlcmFsIHJlYXNv bnMgKGUuZy4gaXQncyB0b28gY291cGxlZCB3aXRoIHRoZSB0cmFuc3BvcnQgbGF5ZXIpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvvvK3vvLMg44K044K3 44OD44KvJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvLCB3ZSBhcmUgc2Vla2luZyBhIHNvbHV0aW9u IHRoYXQgaXMgbW9yZSBpbiBhcHBsaWNhdGlvbiBsYXllci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q777yt77yzIOOCtOOCt+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q777yt77yzIOOC tOOCt+ODg+OCryZxdW90Oztjb2xvcjojMUY0OTdEIj5Ub3NoaW8gSXRvPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDjgrTjgrfjg4Pjgq8mcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhh cmR0QGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMSwg MjAyMSAxMjo1MyBQTTxicj4NCjxiPlRvOjwvYj4gaXRvIHRvc2hpbyg8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuS8iuiXpDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7kv4rlpKs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IOKXizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+77yy77yk77yjPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKWoTwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+77yp77y056CUPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKXizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+77yj77yu77ysPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPikN CiAmbHQ7dG9zaGlvOS5pdG9AdG9zaGliYS5jby5qcCZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRo QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIHNlbGYtaXNzdWVk IGFjY2VzcyB0b2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Xb3VsZCBiZSB1c2VmdWwg dG8gdW5kZXJzdGFuZCB5b3VyIHVzZSBjYXNlIGFuZCB3aGF0IHlvdSB0aGUgZ29hbHMgYW5kIGNv bnN0cmFpbnRzIGFyZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5PbiBUaHUsIFNlcCAzMCwgMjAyMSBhdCA1OjU4IFBNICZsdDs8YSBocmVmPSJt YWlsdG86dG9zaGlvOS5pdG9AdG9zaGliYS5jby5qcCI+dG9zaGlvOS5pdG9AdG9zaGliYS5jby5q cDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowbW0gMG1tIDBtbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MG1t Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBi NDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgRGljayw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1 b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUuIFRoZSBzY2VuYXJpbyBvZiBzZWxmLWlz c3VlZCBhY2Nlc3MgdG9rZW5zIGRvZXNuJ3QgcmVhbGx5IGZvbGxvdyB0aGU8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDssc2VyaWY7Y29sb3I6IzFGNDk3RCI+ bW9kZWwgb2YgT0F1dGguPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFm JnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78y ZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdEIj5TbywgaWYgd2Ug ZG8gc3RhbmRhcmRpemUgc2VsZi1pc3N1ZWQgYWNjZXNzIHRva2VucywgbWF5YmUgT0FVVEggV0cg aXMgbm90IHRoZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90 OyxzZXJpZjtjb2xvcjojMUY0OTdEIj5yaWdodCB2ZW51ZS4gTWF5YmUgSFRUUEJJUyBvciBIVFRQ QVBJIFdHcz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O8O/MmTDvzMzICAwYjQwYjcwYzMwYWYmcXVvdDss c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvDvzJkw78zMyAg MGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7w78yZMO/MzMgIDBiNDBiNzBjMzBhZiZxdW90OyxzZXJpZjtjb2xvcjojMUY0OTdE Ij5Ub3NoaW8gSXRvPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDvDvzJkw78zMyAgMGI0MGI3MGMzMGFmJnF1b3Q7LHNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBEaWNrDQogSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h PiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRlbWJlciAyOSwgMjAyMSAz OjA2IFBNPGJyPg0KPGI+VG86PC9iPiBpdG8gdG9zaGlvKDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+5LyK6JekPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+DQo8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuS/iuWkqzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4g4peLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7v vLLvvKTvvKM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4pahPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7vvKnvvLTnoJQ8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+4peLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij7vvKPvvK7vvKw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+KQ0KICZsdDs8 YSBocmVmPSJtYWlsdG86dG9zaGlvOS5pdG9AdG9zaGliYS5jby5qcCIgdGFyZ2V0PSJfYmxhbmsi PnRvc2hpbzkuaXRvQHRvc2hpYmEuY28uanA8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJl Zj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIHNlbGYtaXNzdWVkIGFjY2Vz cyB0b2tlbnM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZSBjbGllbnQgaXMgc2VuZGluZyBh IHNlbGYtc2lnbmVkIEpXVCB0byB0aGUgUlMsIHlvdSBlc3NlbnRpYWxseSBhcmUganVzdCBhdXRo ZW50aWNhdGluZyBkaXJlY3RseSB0byB0aGUgUlMuIE5vdCByZWFsbHkgT0F1dGggYXMgdGhlIFJT IGhhcyBub3QgZGVsZWdhdGVkDQogYXV0aG9yaXphdGlvbiBhdXRob3JpdHkgdG8gdGhlIEFTLiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PklmIHRoZSBjbGllbnQgc2VuZHMgYSBzZWxmLXNpZ25lZCBKV1QgKGEgUEFSKSB0byB0aGUgQVMs IGFuZCBnZXRzIGJhY2sgYW4gYWNjZXNzIHRva2VuIHRvIHByZXNlbnQgdG8gdGhlIFJTLCB5b3Ug Z2V0IGNlbnRyYWxpemVkIGF1dGhvcml6YXRpb24gZGVjaXNpb25zLCBhIGtleQ0KIGZlYXR1cmUg b2YgT0F1dGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_TYCPR01MB56787D963D23F78B0800C6CBE5AB9TYCPR01MB5678jpnp_--