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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> >>> 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: [email protected] >>>> <mailto:[email protected]> >>>> To: Karsten Meyer zu Selhausen >>>> <[email protected]> >>>> <mailto:[email protected]>, Karsten >>>> zu Selhausen <[email protected]> >>>> <mailto:[email protected]>, Daniel >>>> Fett <[email protected]> <mailto:[email protected]> >>>> >>>> >>>> >>>> >>>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth -- Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
