Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Daniel Fett]

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
>> 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
>>> 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 

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[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
> 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
>> 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
>> mailto:jos...@authlete.com>> wrote:
>>
>> I agree, it is in redundant in the JARM case.
>>
>> I find the text
>> in 

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Takahiko Kawasaki]

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
>>> 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
>>> 

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Vladimir Dzhuvinov]

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 
> 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 

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Takahiko Kawasaki]

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
>> 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 
>> 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}={ISSUER}
>>
>> Or, can the iss response parameter be omitted when JARM is used?
>>
>> A small feedback for the 

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Takahiko Kawasaki]

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
> 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 
> 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}={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 
> 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 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-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 

Re: [OAUTH-WG] New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

[Joseph Heenan]

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  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}={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 > > 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 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-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
>>>  
>>>