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> 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> > 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} > > 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> > 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 >> To: Karsten Meyer zu Selhausen <karsten.meyerzuselhau...@hackmanit.de> >> <karsten.meyerzuselhau...@hackmanit.de>, Karsten zu Selhausen >> <karsten.meyerzuselhau...@hackmanit.de> >> <karsten.meyerzuselhau...@hackmanit.de>, Daniel Fett <m...@danielfett.de> >> <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. >> >> The IETF Secretariat >> >> >> -- >> 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 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 listOAuth@ietf.orghttps://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
