From nobody Mon Nov 16 23:56:12 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84923A11BD for ; Mon, 16 Nov 2020 23:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 IA_G_SwNbh-u for ; Mon, 16 Nov 2020 23:56:07 -0800 (PST) Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (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 A50B23A11AC for ; Mon, 16 Nov 2020 23:56:07 -0800 (PST) Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id evqPkjvaxle7revqQk7AmA; Tue, 17 Nov 2020 00:56:07 -0700 X-CMAE-Analysis: v=2.4 cv=f6KNuM+M c=1 sm=1 tr=0 ts=5fb38217 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=__SxRlIrAAAA:8 a=is3RsFX7AAAA:8 a=ddEIn7SpAAAA:8 a=A1X0JdhQAAAA:8 a=9YbGl7VAAAAA:8 a=AGt6jbFzJ15_AqTjfE4A:9 a=ZzQglzhH7yfu32qe:21 a=58bV5VuECqQEJRzP:21 a=QEXdDO2ut3YA:10 a=idCLnkAckNQA:10 a=LBoxaBkYVh4A:10 a=13CRv-QaNUMA:10 a=pGLkceISAAAA:8 a=aZL1-Zqr0g_DdfdxC8cA:9 a=VqviYuB2Ter2sWrc:21 a=r7aulU3LGZCx6iQa:21 a=YxgiVD8eB8PxfBR3:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22 a=H5r4HjhRfVyZ-DhAOYba:22 a=CvJ-9y_HEmGQg9NJmnFv:22 a=0LcYgHMQs7_kImmFrmno:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=AcK2Xwxry4XOpw9gWFIK:22 X-SECURESERVER-ACCT: vladimir@connect2id.com To: oauth@ietf.org References: <160430230298.9780.18195581822860811409@ietfa.amsl.com> <6f382f32-31ae-9907-4fd0-a88d5ae978bb@connect2id.com> <69B0850B-D863-4792-905E-54EE20823323@authlete.com> <7ddcaef6-0b92-8cd4-e408-32de4a7f4f75@connect2id.com> From: Vladimir Dzhuvinov Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd X-Enigmail-Draft-Status: N11100 Organization: Connect2id Ltd. Message-ID: <61f07b70-f9b2-f5c3-19a2-122062ad1055@connect2id.com> Date: Tue, 17 Nov 2020 09:56:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040302080401090304080507" X-CMAE-Envelope: MS4xfNgUZHx5sJSB5JaBiaLflEFFk2FSU/3TbP8t0liEwDJpER+YzuP2WfkaHeW9dwcG5IhRebfO4zEjyGmH6XwGWSCTi7SYVeAIdRIKXA9wAcp8waaG1BAJ ExD1XScpt9X2v2ZFLO+IRkuhvT1pJo1evPTm7fy75RciIs2XiW9DxhvncgRNQR3JrwLXLTwUmXqIBA== Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 07:56:11 -0000 This is a cryptographically signed message in MIME format. --------------ms040302080401090304080507 Content-Type: multipart/alternative; boundary="------------9D5469F03FBD79A74994286C" Content-Language: en-US This is a multi-part message in MIME format. --------------9D5469F03FBD79A74994286C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Noting two unrelated comments that came up: 1. The iss value in the example doesn't appear to be URL encoded: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth= -resp-01.html#name-example-authorization-respo 2. There was the question from a developer whether error responses should also have the iss. I suggest the spec to be more explicit that iss is added to both success and error responses, and even include a second example, with an error response. Vladimir On 10/11/2020 22:25, Takahiko Kawasaki wrote: > Hi Vladimir, > > Good point. Considering the similarity to JAR (JWT Secured > Authorization Response), if we apply the same logic, our discussion > will eventually reach "response parameters outside the response JWT > are almost meaningless in the context of JARM". For interoperability > and simplicity, it may be good to say "MUST NOT" as you suggested. > > Taka > > On Mon, Nov 9, 2020 at 10:26 PM Vladimir Dzhuvinov > > wrote: > > Re Case 1: When JARM is used: > > A colleague pointed me to the following statement in the JARMs > spec, so I'd suggest to say the "iss" MUST NOT be included when > JARM is used: > > https://openid.net//specs/openid-financial-api-jarm.html#jwt-based-= response-mode > >> All response parameters defined for a given response type are >> conveyed in a JWT > > Now, there isn't a proper normative keyword in this JARM spec > sentence, so I guess some may interpret this as a strong check for > no other query params, while others may not. Hence the MUST NOT to > prevent potential unintended errors. > > What are your thoughts on this? > > Vladimir > > On 06/11/2020 23:34, Takahiko Kawasaki wrote: >> I implemented the draft quickly and found no big hurdle for >> authorization server implementations. The current snapshot of my >> implementation does not add the `iss` parameter when JARM is >> used. However, for interoperability, I feel that the spec should >> describe expected behaviors when a JWT is included in an >> authorization response. The following is an implementer's comment >> for some cases. >> >> Case 1: When JARM is used >> >> An `iss` claim is included in the response JWT as one of >> top-level entries together with response parameters. It is not so >> unnatural to regard the `iss` claim as a response parameter. >> Conclusion would be "When JARM is used, the `iss` parameter is >> not necessary." >> >> Case 2: When an ID token is issued >> >> It is unnatural to regard the `iss` claim in an ID token as a >> response parameter. However, because FAPI Part 2 has already been >> using an ID token as detached signature for integrity protection, >> it would be difficult to find a convincing reason to prohibit >> using the `iss` claim in an ID token as a countermeasure to >> mix-up attacks. Conclusion would be "When an ID token is issued, >> the `iss` parameter is not necessary." >> >> Case 3: When an unencrypted JWT access token is issued >> >> It is technically possible to use the `iss` claim in an >> unencrypted JWT access token as the `iss` parameter. However, >> requiring the client to check the `iss` claim means "The access >> token is no longer opaque to the client." Conclusion would be >> "Even when an access token is issued and its format is JWT, the >> `iss` parameter is necessary." >> >> BTW, I found that a certain system raises an error when an >> unknown response parameter (that is, the `iss` parameter) is >> included in error authorization responses. To ask the >> administrator of the system to regard the `iss` parameter as a >> known one, at least the spec draft needs to be adopted by the >> community as a working draft. I hope that "call for adoption" for >> the draft will be conducted soon. >> >> Best Regards, >> Taka >> >> On Wed, Nov 4, 2020 at 4:46 AM Takahiko Kawasaki >> > wrote: >> >> It sounds that the Security Considerations section or >> somewhere appropriate should have a paragraph like below. >> >> When an authorization response includes a JWT whose `iss` >> claim represents the issuer identifier of the authorization >> server, the `iss` claim can be used as a substitute for the >> `iss` parameter. Therefore, such authorization response does >> not have to have the `iss` parameter outside the JWT >> separately. Examples of such JWTs include the value of the >> `id_token` parameter in OIDC and the value of `response` >> parameter in JARM. >> >> Taka >> >> On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan >> > wrote: >> >> I agree, it is in redundant in the JARM case. >> >> I find the text >> in=C2=A0https://www.ietf.org/archive/id/draft-meyerzuselha= usen-oauth-iss-auth-resp-01.html#name-security-considerations >> (the 4th paragraph where JARM & JWTs) are mentioned a bit >> confusing - I think it would be good to say something >> along the lines of: >> >> Although integrity protection is not necessary to prevent >> mixup, any authorization response method that includes a >> JWT with an =E2=80=98iss' (for example, JARM or OIDC hybri= d flow) >> will prevent the attack (assuming the client is >> validating the iss). >> >> >> I=E2=80=99m not entirely sure I understand what "MUST NOT = allow >> multiple authorization servers to return the same issuer >> identifier during registration=E2=80=9D means as I don=E2=80= =99t think >> https://tools.ietf.org/html/rfc7591 returns the issuer? >> >> It might be clearer to say something like =E2=80=9CWhen >> https://tools.ietf.org/html/rfc8414 is used the client >> MUST implement the validation described in >> https://tools.ietf.org/html/rfc8414#section-3.3. When >> authorization server details can be manually configured >> in the client, the client must verify that all issuer >> values are unique.=E2=80=9D (Or at least something along t= hose >> lines, I=E2=80=99m sure my wording can be improved. But if= the >> client is correctly implementing rfc8414 or OIDC >> discovery [and does not have any manually configured >> authorization servers] then there=E2=80=99s no requirement= for >> any further checks that the issuer is unique.) >> >> Joseph >> >> >>> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov >>> >> > wrote: >>> >>> This can potentially occur. If JARM is used "iss" >>> becomes redundant. To me JARM is an "enhanced" iss. >>> >>> If both are included a sensible client should make sure >>> the iss and the JARM iss match. >>> >>> My suggestion is to not require iss when a JARM is >>> present, but in case both do occur to have the client >>> check both. >>> >>> Vladimir >>> >>> On 02/11/2020 22:34, Takahiko Kawasaki wrote: >>>> Hi Karsten, >>>> >>>> The specification mentions JARM. Does this >>>> specification require the iss response parameter even >>>> when JARM is used? That is, should an authorization >>>> response look like below? >>>> >>>> HTTP/1.1 302 Found >>>> Location: >>>> https://client.example.com/cb?response=3D{JWT}&iss=3D{IS= SUER} >>>> >>>> >>>> Or, can the iss response parameter be omitted when JARM >>>> is used? >>>> >>>> A small feedback for the 3rd paragraph in Section 4: >>>> s/identifes/identifies/ >>>> >>>> Best Regards, >>>> Taka >>>> =C2=A0 >>>> >>>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov >>>> >>> > wrote: >>>> >>>> Thanks Karsten, looks good to me now, no further >>>> comments. >>>> >>>> Vladimir >>>> >>>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrot= e: >>>>> >>>>> Hi all, >>>>> >>>>> Daniel and I published a new version of the "iss" >>>>> response parameter draft to address the feedback >>>>> from the WG. >>>>> >>>>> Changes in -01: >>>>> >>>>> * Incorporated first WG feedback >>>>> * Clarifications for use with OIDC >>>>> * Added note that clients supporting just one AS >>>>> are not vulnerable >>>>> * Renamed metadata parameter >>>>> * Various editorial changes >>>>> >>>>> >>>>> We would like to ask you for further feedback and >>>>> comments on the new draft version. >>>>> >>>>> Best regards, >>>>> Karsten >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: New Version Notification for >>>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt >>>>> Date: Sun, 01 Nov 2020 23:31:42 -0800 >>>>> From: internet-drafts@ietf.org >>>>> >>>>> To: Karsten Meyer zu Selhausen >>>>> >>>>> , >>>>> Karsten zu Selhausen >>>>> >>>>> , >>>>> Daniel Fett >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> A new version of I-D, >>>>> draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt >>>>> has been successfully submitted by Karsten Meyer >>>>> zu Selhausen and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-meyerzuselhausen-oauth-iss-auth-resp >>>>> Revision: 01 >>>>> Title: OAuth 2.0 Authorization Server Issuer >>>>> Identifier in Authorization Response >>>>> Document date: 2020-11-01 >>>>> Group: Individual Submission >>>>> Pages: 10 >>>>> URL: >>>>> https://www.ietf.org/archive/id/draft-meyerzuselhau= sen-oauth-iss-auth-resp-01.txt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-meyerzuselha= usen-oauth-iss-auth-resp/ >>>>> Html: >>>>> https://www.ietf.org/archive/id/draft-meyerzuselhau= sen-oauth-iss-auth-resp-01.html >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-meyerzuselhausen-= oauth-iss-auth-resp-01 >>>>> Diff: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuse= lhausen-oauth-iss-auth-resp-01 >>>>> >>>>> Abstract: >>>>> This document specifies a new parameter "iss" that >>>>> is used to >>>>> explicitly include the issuer identifier of the >>>>> authorization server >>>>> in the authorization response of an OAuth >>>>> authorization flow. If >>>>> implemented correctly, the "iss" parameter serves >>>>> as an effective >>>>> countermeasure to "mix-up attacks". >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes >>>>> from the time of submission >>>>> until the htmlized version and diff are available >>>>> at tools.ietf.org . >>>>> >>>>> The IETF Secretariat >>>>> >>>>> >>>>> --=20 >>>>> Karsten Meyer zu Selhausen >>>>> IT Security Consultant >>>>> Phone: +49 (0)234 / 54456499 >>>>> Web: https://hackmanit.de |= IT Security Consulting, Penetration Testing, Security Training >>>>> >>>>> Does your OAuth or OpenID Connect implementation us= e PKCE to strengthen the security? Learn more about the procetion PKCE pr= ovides and its limitations in our new blog post: >>>>> https://www.hackmanit.de/en/blog-en/123-when-pkce-c= annot-protect-your-confidential-oauth-client >>>>> >>>>> 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 Schw= enk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemiet= z >>>>> >>>>> _______________________________________________ >>>>> 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.ietf.org/mailman/listinfo/oauth > > --=20 > Vladimir Dzhuvinov > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------9D5469F03FBD79A74994286C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Noting two unrelated comments that came up:

  1. The iss value in the example doesn't appear to be URL encoded:

    https://www.ietf.org/archive/id/draft-meyerzuselhausen-oaut= h-iss-auth-resp-01.html#name-example-authorization-respo


  2. There was the question from a developer whether error responses should also have the iss. I suggest the spec to be more explicit that iss is added to both success and error responses, and even include a second example, with an error response.

Vladimir

On 10/11/2020 22:25, Takahiko Kawasaki= wrote:
Hi Vladimir,

Good point. Considering the similarity to JAR (JWT Secured Authorization Response), if we apply the same logic, our discussion will eventually reach "response parameters outside the response JWT are almost meaningless in the context of JARM". For interoperability and simplicity, it may be good to say "MUST NOT" as you suggested.

Taka

On Mon, Nov 9, 2020 at 10:2= 6 PM Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=

Re Case 1: When JARM is used:

A colleague pointed me to the following statement in the JARMs spec, so I'd suggest to say the "iss" MUST NOT be included when JARM is used:

https://openid= =2Enet//specs/openid-financial-api-jarm.html#jwt-based-response-mode<= /p>

All response parameters defined for= a given response type are conveyed in a JWT

Now, there isn't a proper normative keyword in this JARM spec sentence, so I guess some may interpret this as a strong check for no other query params, while others may not. Hence the MUST NOT to prevent potential unintended errors.

What are your thoughts on this?

Vladimir

On 06/11/2020 23:34, Takahiko Kawasaki wrote:
I implemented the draft quickly and found no big hurdle for authorization server implementations. The current snapshot of my implementation does not add the `iss` parameter when JARM is used. However, for interoperability, I feel that the spec should describe expected behaviors when a JWT is included in an authorization response. The following is an implementer's comment for some cases.

Case 1: When JARM is used

An `iss` claim is included in the response JWT as one of top-level entries together with response parameters. It is not so unnatural to regard the `iss` claim as a response parameter. Conclusion would be "When JARM is used, the `iss` parameter is not necessary."

Case 2: When an ID token is issued

It is unnatural to regard the `iss` claim in an ID token as a response parameter. However, because FAPI Part 2 has already been using an ID token as detached signature for integrity protection, it would be difficult to find a convincing reason to prohibit using the `iss` claim in an ID token as a countermeasure to mix-up attacks. Conclusion would be "When an ID token is issued, the `iss` parameter is not necessary."

Case 3: When an unencrypted JWT access token is issued
It is technically possible to use the `iss` claim in an unencrypted JWT access token as the `iss` parameter. However, requiring the client to check the `iss` claim means "The access token is no longer opaque to the client." Conclusion would be "Even when an access token is issued and its format is JWT, the `iss` parameter is necessary."

BTW, I found that a certain system raises an error when an unknown response parameter (that is, the `iss` parameter) is included in error authorization responses. To ask the administrator of the system to regard the `iss` parameter as a known one, at least the spec draft needs to be adopted by the community as a working draft. I hope that "call for adoption" for the draft will be conducted soon.

Best Regards,
Taka

On Wed, Nov 4, 2020= at 4:46 AM Takahiko Kawasaki <taka@authlete.com> wrote:
It sounds that the Security Considerations section or somewhere appropriate should have a paragraph like below.

When an authorization response includes a JWT whose `iss` claim represents the issuer identifier of the authorization server, the `iss` claim can be used as a substitute for the `iss` parameter. Therefore, such authorization response does not have to have the `iss` parameter outside the JWT separately. Examples of such JWTs include the value of the `id_token` parameter in OIDC and the value of `response` parameter in JARM.

Taka

On Tue, Nov 3, 2020 at 10:46 PM Joseph Heenan <joseph= @authlete.com> wrote:
I agree, it is in redundant in the JARM case.

I find the text in=C2=A0ht= tps://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-= 01.html#name-security-considerations (the 4th paragraph where JARM & JWTs) are mentioned a bit confusing - I think it would be good to say something along the lines of:

Although integrity protection is not necessary to prevent mixup, any authorization response method that includes a JWT with an =E2=80=98iss' (for example, JARM or OIDC hybrid= flow) will prevent the attack (assuming the client is validating the iss).


I=E2=80=99m not entirely sure I understand w= hat "MUST NOT allow multiple authorization servers to return the same issuer identifier during registration=E2=80=9D means as I don=E2=80=99t = think ht= tps://tools.ietf.org/html/rfc7591 returns the issuer?

It might be clearer to say something like =E2=80=9CWhen ht= tps://tools.ietf.org/html/rfc8414 is used the client MUST implement the validation described in ht= tps://tools.ietf.org/html/rfc8414#section-3.3. When authorization server details can be manually configured in the client, the client must verify that all issuer values are unique.=E2=80=9D (Or at least something along t= hose lines, I=E2=80=99m sure my wording can be impro= ved. But if the client is correctly implementing rfc8414 or OIDC discovery [and does not have any manually configured authorization servers] then there=E2=80=99s no requirement for any fur= ther checks that the issuer is unique.)

Joseph


On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

This can potentially occur. If JARM is used "iss" becomes redundant. To me JARM is an "enhanced" iss.

If both are included a sensible client should make sure the iss and the JARM iss match.

My suggestion is to not require iss when a JARM is present, but in case both do occur to have the client check both.

Vladimir

On 02/11/2020 22:34, Takahiko Kawasaki wrote:
Hi Karsten,

The specification mentions JARM. Does this specification require the iss response parameter even when JARM is used? That is, should an authorization response look like below?

HTTP/1.1 302 Found

Or, can the iss response parameter be omitted when JARM is used?

A small feedback for the 3rd paragraph in Section 4: s/identifes/identifies/

Best Regards,
Taka
=C2=A0

On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov <vladim= ir@connect2id.com> wrote:

Hi all,

Dani= el and I published a new version of the "iss" response parameter draft to address the feedback from the WG.

Chan= ges in -01:

  • In= corporated first WG feedback
  • Cl= arifications for use with OIDC
  • Ad= ded note that clients supporting just one AS are not vulnerable
  • Re= named metadata parameter
  • Va= rious editorial changes

= We would like to ask you for further feedback and comments on the new draft version.

=
Best= regards,
Kars= ten

-------- Forwarded Message -------- =
Sub= ject: New Version Notification for draft-meyerzuselhau= sen-oauth-iss-auth-resp-01.txt
Dat= e: Sun, 01 Nov 2020 23:31:42 -0800
Fro= m: internet-drafts@ietf.org
To:= Karsten Meyer zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>, Karsten zu Selhausen <karsten.meyerzuselhausen@hackmanit.de>, Daniel Fett <mail@danielfett.de>



A new version of I-D, draft-meyerzuselhausen-oaut= h-iss-auth-resp-01.txt
has been successfully submitted by Karsten Meyer zu Selhausen and posted to the
IETF repository.

Name: draft-meyerzuselhausen-oaut= h-iss-auth-resp
Revision: 01
Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response
Document date: 2020-11-01 Group: Individual Submission
Pages: 10
URL: = https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res= p-01.txt
Status: = https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-re= sp/
Html: = https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-res= p-01.html
Htmlized: = https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01=
Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-meyerzuselhausen-oauth-iss-auth= -resp-01

Abstract:
This document specifies a new parameter "iss" that is used to
explicitly include the issuer identifier of the authorization server
in the authorization response of an OAuth authorization flow. If
implemented correctly, the "iss" parameter serves as an effective
countermeasure to "mix-up attacks".



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

The IETF Secretariat


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

Does your OAuth or OpenID Connect implementation use PKCE to strengthen t=
he security? Learn more about the procetion PKCE provides and its limitat=
ions in our new blog post:
https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-you=
r-confidential-oauth-client

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, Dr. Marcus Niemietz

________________________=
_______________________
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/mai= lman/listinfo/oauth

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


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

--------------9D5469F03FBD79A74994286C-- --------------ms040302080401090304080507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CzMwggUbMIIEA6ADAgECAhBs/e7jES6a32XKZxs4R01iMA0GCSqGSIb3DQEBCwUAMIGWMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE5MTEwMjAwMDAw MFoXDTIxMTEwMTIzNTk1OVowKDEmMCQGCSqGSIb3DQEJARYXdmxhZGltaXJAY29ubmVjdDJp ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG5mL+CcvSppMj/W8Kd0/E 1/y5/s94gmbIFzEugHyMPV2dd6lusiALe35QCtu3e8Wy6FkCwzxWmmzhF4FY/e4uPbDjco3w /GgHhz2KXe385u31c32/uM3jRqhYT5JvmXxte/GgmjcW1yWcPkKEz/sCezdIYpI9Pek+P4Gr xmbt8H+wJrwfrXKTJXXT+gFjCcZDRLm67X4U57TsaCoezTe7zOoPX9zxMTyZD/cvC/SfuVxQ U60ZsfZzdcgPwScgy3JaiPegcbnqqebjJqtRx42eRjrBZ1/u411rHN2QQLgiih7D1/4PJC9f /8nHgaerLy3ogdu1dw5+vQ1TRIYBmcIXAgMBAAGjggHQMIIBzDAfBgNVHSMEGDAWgBQJwPL8 C9qU21/+K9+omULPyeCtADAdBgNVHQ4EFgQU446sriG/NgywLZA2oBG79Yr2qyAwDgYDVR0P AQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MEAGA1UdIAQ5MDcwNQYMKwYBBAGyMQECAQEBMCUwIwYIKwYBBQUHAgEWF2h0dHBzOi8vc2Vj dGlnby5jb20vQ1BTMFoGA1UdHwRTMFEwT6BNoEuGSWh0dHA6Ly9jcmwuc2VjdGlnby5jb20v U2VjdGlnb1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYoG CCsGAQUFBwEBBH4wfDBVBggrBgEFBQcwAoZJaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0 aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAjBggrBgEF BQcwAYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJAY29u bmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAEE73kCtUigl/bhLrqS6AsCU+jKm1fxq BY09+ktBwVcu5WgM18Uov3WvzVnjXn5BNNVM3RwhWFXyW3pPnDPyjqgxcpfoyY5SJEzvcPlu wm69z/dzqasVhsHPIFSjACnUBrFZPsq/abMQr4yFOMVyX/EudYgmZVu2Er9Ui7YbTO1Nolap xlseQIgQhVcr7aSs02PLDANuwW/asgKExYzhPdt9MF1lezj968Mv74kRo1T/lm5RFNfh2QdM 9C0n1t+qRCrRF1VbsiTgChjazgNGbvl12bOAujX0up4hqw+7PaCcI3Mpyv/rKKKrRG52iCcv cMHX344tOqKM/DIdF/0WNpkwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqG SIb3DQEBDAUAMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UE BxMLSmVyc2V5IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UE AxMlVVNFUlRydXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAw MDBaFw0zMDEyMzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQx PjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJl IEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno 1jvm2pK/KxBOqhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK 8dtK56NCSrq4iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0k N+oHox+L9aV1rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee 1sLTHsLtpiK9OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8 kHPo5fZl5u1B0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAU U3m/WqorSs9UgOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4G A1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2NybC51c2VydHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHku Y3JsMHYGCCsGAQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3Qu Y29tL1VTRVJUcnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2Nz cC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADd F9d6HBA4kMjjsb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou7 4TZ/XTarHG8zdMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0 sZYx4rXD6+cqFq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJ JIXwKjYA6VUR/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUH xvBz9OfYWUiXu09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZe roXaecG03i3mM7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85 F2w2ZpXfP+w8q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymU E0pwi/KDaiYB15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uY dBEQkkDc+lKB1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe 5W8mybM2JzGCBDIwggQuAgEBMIGrMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0 ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01iMA0GCWCGSAFlAwQCAQUAoIICVzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDExMTcwNzU2MDVaMC8G CSqGSIb3DQEJBDEiBCAEtKF8lFcIjlnJpBUYXP2g1mOz2beUv5DNZl5R+WGXrjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG8Bgkr BgEEAYI3EAQxga4wgaswgZYxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE+MDwG A1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEGz97uMRLprfZcpnGzhHTWIwgb4GCyqGSIb3DQEJEAILMYGuoIGrMIGWMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNlY3RpZ28gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBs/e7jES6a32XKZxs4R01i MA0GCSqGSIb3DQEBAQUABIIBAB+i4qN9oEpkWimtogIQqBD9sLkDRszrsQ3nDRqZ8U8huWwq WFLXPFwkEpC3Dqf2cQaAYAB989msqNGtmHclP5j0F86dbQUBeip7pQbxb6dd+WvQsi+NxXpG 82JNFsIjEyo0HV+Ux0BpF1v+KD/t9OG14kORU4mN/ifKZNQpq2YQkPG6gx5ck/pPJV7POn+U ENAbyqZSJTLVA5BwbTWm+HqzI+tnP/+4dS8PHTTPOrCpN3qARJms7k+8N0On4/NwW0p2VrCZ HOwU/j/IxFxL6gS54+BS0klzEqz5FJc/s3/Ix5uPIjXR4neu7/x7p6EzouBK7Ntk3e5NfeiQ CmPbf5cAAAAAAAA= --------------ms040302080401090304080507--