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
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
