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] PAR Shepherd Review

[Brian Campbell]

On Tue, Nov 10, 2020 at 2:44 AM Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> I am in the process of writing my shepherd write-up for the PAR document
> and wanted to make sure that I properly understand the document.
>
> The introduction says:
>
>
>
> “
>
>
>
>This document [PAR] complements JAR by providing an interoperable way
> to
>
>push the payload of an authorization request directly to the
>
>authorization server in exchange for a "request_uri" value usable at
>
>the authorization server in a subsequent authorization request.
>
> “
>
>
>
> JAR provides the ability to send Authorization Request parameters in a JWT
> format protected with JWS and optionally JWE. It allows the JAR to be
> conveyed by value and by reference but does not define how the client would
> upload the JAR and how to obtain the reference.
>

For pass-by-reference JAR really only covers the case where the client
hosts the request object at some HTTPS URL that it controls and the value
of that URL is the request_uri. PAR defines how the AS can host/hold the
authorization request data and how a client can deliver it directly to the
AS.



>
>
> PAR defines how the client uploads the request object and how to obtain
> the reference. It relies primarily on TLS to protect the communication but
> mentions that it is possible to also use the JWT-based approach suggested
> by JAR.
>

Primarily TLS but also client authentication. A JWT request object can also
be used.


>
> Both drafts claim to have solved the security issues of protecting the
> communication through the user agent.
>

JAR is really the one that solved that. PAR provides a simple interoperable
way for a client to use JAR's request_uri by 'pushing' the content of an
authorization request directly to the AS and getting a request_uri
reference value in exchange.


>
>
> Is this a correct summary?
>

I think so, yes, along with my notes/clarifications.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] PAR Shepherd Review

[Hannes Tschofenig]

Hi all,

I am in the process of writing my shepherd write-up for the PAR document and 
wanted to make sure that I properly understand the document.
The introduction says:

"

   This document [PAR] complements JAR by providing an interoperable way to
   push the payload of an authorization request directly to the
   authorization server in exchange for a "request_uri" value usable at
   the authorization server in a subsequent authorization request.
"

JAR provides the ability to send Authorization Request parameters in a JWT 
format protected with JWS and optionally JWE. It allows the JAR to be conveyed 
by value and by reference but does not define how the client would upload the 
JAR and how to obtain the reference.

PAR defines how the client uploads the request object and how to obtain the 
reference. It relies primarily on TLS to protect the communication but mentions 
that it is possible to also use the JWT-based approach suggested by JAR.

Both drafts claim to have solved the security issues of protecting the 
communication through the user agent.

Is this a correct summary?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth