Thanks Vladimir and Takahiko, we incorporated your proposals into the next version of the draft.
-Daniel Am 17.11.20 um 08:56 schrieb Vladimir Dzhuvinov: > > 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 >> <vladi...@connect2id.com <mailto:vladi...@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.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 >>> <t...@authlete.com <mailto:t...@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 >>> <jos...@authlete.com <mailto:jos...@authlete.com>> wrote: >>> >>> I agree, it is in redundant in the JARM case. >>> >>> I find the text >>> in >>> https://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 ‘iss' (for example, JARM or OIDC >>> hybrid flow) will prevent the attack (assuming the >>> client is validating the iss). >>> >>> >>> I’m not entirely sure I understand what "MUST NOT allow >>> multiple authorization servers to return the same issuer >>> identifier during registration” means as I don’t think >>> https://tools.ietf.org/html/rfc7591 returns the issuer? >>> >>> It might be clearer to say something like “When >>> 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.” (Or at least something along those >>> lines, I’m 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’s no requirement for >>> any further checks that the issuer is unique.) >>> >>> Joseph >>> >>> >>>> On 3 Nov 2020, at 07:01, Vladimir Dzhuvinov >>>> <vladi...@connect2id.com >>>> <mailto:vladi...@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 >>>>> Location: >>>>> https://client.example.com/cb?response={JWT}&iss={ISSUER} >>>>> >>>>> <https://client.example.com/cb?response=%7BJWT%7D&iss=%7BISSUER%7D> >>>>> >>>>> 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 >>>>> >>>>> >>>>> On Tue, Nov 3, 2020 at 3:13 AM Vladimir Dzhuvinov >>>>> <vladi...@connect2id.com >>>>> <mailto:vladi...@connect2id.com>> wrote: >>>>> >>>>> Thanks Karsten, looks good to me now, no further >>>>> comments. >>>>> >>>>> Vladimir >>>>> >>>>> On 02/11/2020 09:54, Karsten Meyer zu Selhausen wrote: >>>>>> >>>>>> 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-dra...@ietf.org >>>>>> <mailto:internet-dra...@ietf.org> >>>>>> To: Karsten Meyer zu Selhausen >>>>>> <karsten.meyerzuselhau...@hackmanit.de> >>>>>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, >>>>>> Karsten zu Selhausen >>>>>> <karsten.meyerzuselhau...@hackmanit.de> >>>>>> <mailto:karsten.meyerzuselhau...@hackmanit.de>, >>>>>> Daniel Fett <m...@danielfett.de> >>>>>> <mailto:m...@danielfett.de> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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-meyerzuselhausen-oauth-iss-auth-resp-01.txt >>>>>> Status: >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ >>>>>> Html: >>>>>> >>>>>> https://www.ietf.org/archive/id/draft-meyerzuselhausen-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=draft-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 <http://tools.ietf.org/>. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>>> >>>>>> -- >>>>>> Karsten Meyer zu Selhausen >>>>>> IT Security Consultant >>>>>> Phone: +49 (0)234 / 54456499 >>>>>> Web: https://hackmanit.de <https://hackmanit.de/> | >>>>>> IT Security Consulting, Penetration Testing, Security Training >>>>>> >>>>>> Does your OAuth or OpenID Connect implementation use >>>>>> PKCE to strengthen the security? Learn more about the procetion PKCE >>>>>> provides and its limitations in our new blog post: >>>>>> >>>>>> https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client >>>>>> >>>>>> Hackmanit GmbH >>>>>> Universitätsstraße 60 (Exzenterhaus) >>>>>> 44789 Bochum >>>>>> >>>>>> Registergericht: Amtsgericht Bochum, HRB 14896 >>>>>> Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj >>>>>> Somorovsky, Dr. Christian Mainka, Dr. Marcus Niemietz >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >> >> -- >> Vladimir Dzhuvinov >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto: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
