Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 8 Jan 2020 23:58:11 +0000

It would be more appropriate to add the text to JAR rather than PAR. It doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR also highlights the weirdness of giving PAR special treatment.

What if we changed this sentence in Section 5.2 of JAR:

The contents of the resource referenced by the URI MUST be a Request

Object.

To:

The contents of the resource referenced by the URI MUST be a Request

Object, unless the URI was provided to the client by the Authorization

Server.

This would allow for use cases such as an AS that provides pre-defined request URIs, or vends request URIs via a client management console, or bakes them into their client apps.

–

Annabelle Richard Backman

AWS Identity

On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=[email-masked]> wrote:

    Hi,

    you are right, PAR does not require the AS to represent the request as a JWT-based request object. The URI is used as internal reference only. That why the draft states

    "There is no need to make the

          authorization request data available to other parties via this

          URI.”

    This difference matters from an AS implementation perspective, it doesn't matter from a client's (interop) perspective.

    We may add a statement to PAR saying that request_uris issued by the PAR mechanism (MAY) deviate from the JAR definition.

    best regards,

    Torsten.

    > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=[email-masked]> wrote:

    > Hi all,

    > The current drafts of PAR (-00) and JAR (-20) require that the AS transform all pushed requests into JWTs. This requirement arises from the following:

    >         • PAR uses the request_uri parameter defined in JAR to communicate the pushed request to the authorization endpoint.

    >         • According to JAR, the resource referenced by request_uri MUST be a Request Object. (Section 5.2)

    >         • Request Object is defined to be a JWT containing all the authorization request parameters. (Section 2.1)

    > There is no need for this requirement to support interoperability, as this is internal to the AS. It is also inconsistent with the rest of JAR, which avoids attempting to define the internal communications between the two AS endpoints. Worse, this restriction makes it harder for the authorization endpoint to leverage validation and other work performed at the PAR endpoint, as the state or outcome of that work must be forced into the JWT format (or retrieved via a subsequent service call or database lookup).

    > –

    > Annabelle Richard Backman

    > AWS Identity

    > _______________________________________________

    > OAuth mailing list

    > [email-masked]

    > https://www.ietf.org/mailman/listinfo/oauth

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 9 Jan 2020 09:56:14 +0100

I would assume given the status of JAR, we don’t want to change it. And as I said, this difference does not impact interoperability from client perspective.

> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=[email-masked]>:
> 
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 9 Jan 2020 19:33:43 +0000

If we address this in PAR, I suggest something along the lines of the following:

As defined in [JAR], the request_uri parameter is required to reference a Request Object JWT. An AS MAY violate this requirement when it is generating request URIs intended for its own consumption (e.g., URIs for pushed requests). This requirement exists to ensure interoperability in cases where the provider of the request_uri is a separate entity from the consumer, such as when a client provides a URI referencing an object stored on the client’s backend service. When the AS is both provider and consumer, this interoperability concern does not apply.

–

From: OAuth <[email-masked]> on behalf of Torsten Lodderstedt <torsten=[email-masked]>
Date: Thursday, January 9, 2020 at 12:56 AM
To: "Richard Backman, Annabelle" <richanna=[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs

Object.

To:

Server.

–

AWS Identity

    Hi,

          URI.”

    best regards,

    Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 9 Jan 2020 20:47:47 +0100

Thanks for the text proposal. It works for me.

> Am 09.01.2020 um 20:34 schrieb Richard Backman, Annabelle <richanna=[email-masked]>:
> 
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jan 2020 11:45:08 -0700

Agree and agree. But given that the change suggested by Annabelle has no
impact on the client or interoperability, perhaps Nat or John could work
the change into the draft during the edits that happen during the final
stages of things?

On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> I would assume given the status of JAR, we don’t want to change it. And as
> I said, this difference does not impact interoperability from client
> perspective.
>
> It would be more appropriate to add the text to JAR rather than PAR. It
> doesn't seem right for PAR to retcon rules in JAR. Moving the text to JAR
> also highlights the weirdness of giving PAR special treatment.
>
>
>
> This would allow for use cases such as an AS that provides pre-defined
> request URIs, or vends request URIs via a client management console, or
> bakes them into their client apps.
>
>
>
> –
>
>     you are right, PAR does not require the AS to represent the request as
> a JWT-based request object. The URI is used as internal reference only.
> That why the draft states
>
>
>
>     This difference matters from an AS implementation perspective, it
> doesn't matter from a client's (interop) perspective.
>
>
>
>     We may add a statement to PAR saying that request_uris issued by the
> PAR mechanism (MAY) deviate from the JAR definition.
>
>
>
>     best regards,
>
>     Torsten.
>
>
>
>     > The current drafts of PAR (-00) and JAR (-20) require that the AS
> transform all pushed requests into JWTs. This requirement arises from the
> following:
>
>     >         • PAR uses the request_uri parameter defined in JAR to
> communicate the pushed request to the authorization endpoint.
>
>     >         • Request Object is defined to be a JWT containing all the
> authorization request parameters. (Section 2.1)
>
>     >
>
>     > There is no need for this requirement to support interoperability,
> as this is internal to the AS. It is also inconsistent with the rest of
> JAR, which avoids attempting to define the internal communications between
> the two AS endpoints. Worse, this restriction makes it harder for the
> authorization endpoint to leverage validation and other work performed at
> the PAR endpoint, as the state or outcome of that work must be forced into
> the JWT format (or retrieved via a subsequent service call or database
> lookup).
>
>     >
>
>     > –
>

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

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Jan 2020 16:48:28 -0300

It may be a challenge to change text saying that the contents of the
resource could be something other than a request object.

If not a request object then what and how is that interoperable are likely
AD questions.

I could perhaps see changing it to must be a request object, or other
format defined by a profile.

John B.

On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <[email-masked]>
wrote:

>> I would assume given the status of JAR, we don’t want to change it. And
>> as I said, this difference does not impact interoperability from client
>> perspective.
>>
>>     you are right, PAR does not require the AS to represent the request
>> as a JWT-based request object. The URI is used as internal reference only.
> *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.*

---

From: Brian Campbell <[email-masked]>
Date: Fri, 10 Jan 2020 12:56:52 -0700

Sure but the text proposed (or something like it) qualifies it such that
there aren't interoperability questions because it's only an implementation
detail to the AS who both produces the URI and consumes its content.

---

From: John Bradley <[email-masked]>
Date: Fri, 10 Jan 2020 17:28:29 -0300

If we assume the client posts a JAR and gets back a reference.  Then the
reference is to a JAR.

I think I see the problem.  If the server providing the reference is
associated with the AS then the server dosen't need to dereference the
object via HTTP, so it could be a URN as an example.

So yes it is not a interoperability issue for the client.

I will think about how I can finesse that.

I agree it is not a change in intent.

I will see if I can get our AD to accept that.

John B.

On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <[email-masked]>
wrote:

>> If not a request object then what and how is that interoperable are
>> likely AD questions.
>>
>>>>     We may add a statement to PAR saying that request_uris issued by
>>>> the PAR mechanism (MAY) deviate from the JAR definition.
>>>>
>>>>
>>>>
>>>>     best regards,
>>>>
>>>>     Torsten.
>>>>
>>>>
>>>>
>>>>     >         • According to JAR, the resource referenced by
>>>> request_uri MUST be a Request Object. (Section 5.2)
>>>>
>>>>     >         • Request Object is defined to be a JWT containing all
>>>> the authorization request parameters. (Section 2.1)
>>>>
>>>>     >
>>>>
>>>>     > There is no need for this requirement to support
>>>> interoperability, as this is internal to the AS. It is also inconsistent
>>>> with the rest of JAR, which avoids attempting to define the internal
>>>> communications between the two AS endpoints. Worse, this restriction makes
>>>> it harder for the authorization endpoint to leverage validation and other
>>>> work performed at the PAR endpoint, as the state or outcome of that work
>>>> must be forced into the JWT format (or retrieved via a subsequent service
>>>> call or database lookup).
>>>>
>>>>     >
>>>>
>>>>     > –
>>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 10 Jan 2020 20:41:07 +0000

Correct. The problem becomes pretty clear in the context of PAR, where the AS is generating and vending out the URI at the PAR endpoint, and consuming it at the authorization endpoint. From an interoperability standpoint, it’s analogous to the AS vending an authorization code at the authorization endpoint and consuming it at the token endpoint.
–
Annabelle Richard Backman
AWS Identity

From: John Bradley <[email-masked]>
Date: Friday, January 10, 2020 at 12:29 PM
To: Brian Campbell <[email-masked]>
Cc: Torsten Lodderstedt <[email-masked]>, Nat Sakimura <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, oauth <[email-masked]>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become JWTs

If we assume the client posts a JAR and gets back a reference.  Then the reference is to a JAR.

I think I see the problem.  If the server providing the reference is associated with the AS then the server dosen't need to dereference the object via HTTP, so it could be a URN as an example.

John B.

On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
Sure but the text proposed (or something like it) qualifies it such that there aren't interoperability questions because it's only an implementation detail to the AS who both produces the URI and consumes its content.

On Fri, Jan 10, 2020 at 12:48 PM John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
It may be a challenge to change text saying that the contents of the resource could be something other than a request object.

If not a request object then what and how is that interoperable are likely AD questions.

I could perhaps see changing it to must be a request object, or other format defined by a profile.

John B.

On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
Agree and agree. But given that the change suggested by Annabelle has no impact on the client or interoperability, perhaps Nat or John could work the change into the draft during the edits that happen during the final stages of things?

On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]>> wrote:
I would assume given the status of JAR, we don’t want to change it. And as I said, this difference does not impact interoperability from client perspective.

Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>>:

Object.

To:

Server.

–

AWS Identity

On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=[email-masked]<mailto:[email-masked]>> wrote:

    Hi,

          URI.”

    best regards,

    Torsten.

    > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=[email-masked]<mailto:[email-masked]>> wrote:

    > [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

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.

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.

---

From: Justin Richer <[email-masked]>
Date: Fri, 10 Jan 2020 15:55:55 -0500

So we could solve this by saying the resulting data object of a PAR is a request object. Which might also contain a request object internally as well. In that case JAR should back off from saying it’s a JWT and instead say it’s a request object. Or we define a new term for this authorization request blob thing.

Or PAR could at least say that if it’s dereferenced over a remote protocol then it MUST be a JWT, but otherwise it can be whatever you want. That’s where the real interop concerns come in.

 — Justin

> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <richanna=[email-masked]> wrote:
> 
> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> On Fri, Jan 10, 2020 at 12:48 PM John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]>>:
>>>>>> 
>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt" <torsten=[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>  
>>>>>>     Hi, 
>>>>>>     
>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle <richanna=[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>     > 
>>>>>>     > Hi all,
>>>>>>     >  
>>>>>>     > [email-masked] <mailto:[email-masked]>
>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>     
>>>>>>     
>>>>> 
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 11 Jan 2020 12:28:05 +0200

My suggestion is to abstain from specifying the concrete form of the
resource pointed to by the PAR URI. Regardless of URI type (URN,
downloadable https URL or something else), and even if the PAR endpoint
and the authZ endpoint are managed by two different entities
(microservice or other scenario).

In the Connect2id implementation of PAR the returned URI doesn't point
to a request object and it doesn't point to a JWT either. It points to
an internally stored "pre-processed" authZ request, which the authZ
endpoint then picks up to complete the authZ.

Even if we eventually end up in microservice world, or allow the PAR
endpoint to be managed by some external entity, the PAR URI - its
interpretation, validation and potentially resource retrieval (JWT or
other blob), is an "internal contract" on the AS side. This doesn't
concern the client, and in OAuth 2.0 the role of AS is indivisible.

I see PAR request + authZ request as one logical OAuth 2.0 authZ
request: the client submits an authZ request and gets an authZ response
at the end. The URI is necessary for the client to proceed from the 1st
to the 2nd step. If we manage to frame / word the PAR URI in this
logical way, without getting stuck in the JAR definition / framing of
what the request_uri / object is, it would be great.

The normative language I think should focus on maintaining the OAuth 2.0
contract for the entire logical authZ request, together with the basic
contracts of 1) JAR and the 2) authZ endpoint.

Vladimir

On 10/01/2020 22:55, Justin Richer wrote:
> So we could solve this by saying the resulting data object of a PAR is
> a request object. Which might also contain a request object internally
> as well. In that case JAR should back off from saying it’s a JWT and
> instead say it’s a request object. Or we define a new term for this
> authorization request blob thing.
>
> Or PAR could at least say that if it’s dereferenced over a remote
> protocol then it MUST be a JWT, but otherwise it can be whatever you
> want. That’s where the real interop concerns come in.
>
>  — Justin
>
>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle
>> <richanna=[email-masked]
>> <mailto:richanna=[email-masked]>> wrote:
>>
>> Correct. The problem becomes pretty clear in the context of PAR,
>> where the AS is generating and vending out the URI at the PAR
>> endpoint, and consuming it at the authorization endpoint. From an
>> interoperability standpoint, it’s analogous to the AS vending an
>> authorization code at the authorization endpoint and consuming it at
>> the token endpoint.
>> – 
>> *From: *John Bradley <[email-masked] <mailto:[email-masked]>>
>> *Date: *Friday, January 10, 2020 at 12:29 PM
>> *To: *Brian Campbell <[email-masked]
>> <mailto:[email-masked]>>
>> *Cc: *Torsten Lodderstedt <[email-masked]
>> <mailto:[email-masked]>>, Nat Sakimura <[email-masked]
>> <mailto:[email-masked]>>, "Richard Backman, Annabelle"
>> <[email-masked] <mailto:[email-masked]>>, oauth
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests
>> must become JWTs
>>  
>> associated with the AS then the server dosen't need to dereference
>> the object via HTTP, so it could be a URN as an example. 
>>  
>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>> Sure but the text proposed (or something like it) qualifies it such
>>> that there aren't interoperability questions because it's only an
>>> implementation detail to the AS who both produces the URI and
>>> consumes its content.
>>>  
>>>> It may be a challenge to change text saying that the contents of
>>>> the resource could be something other than a request object. 
>>>>  
>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> Agree and agree. But given that the change suggested by Annabelle
>>>>> has no impact on the client or interoperability, perhaps Nat or
>>>>> John could work the change into the draft during the edits that
>>>>> happen during the final stages of things?
>>>>>  
>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt
>>>>> <torsten=[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>>> I would assume given the status of JAR, we don’t want to change
>>>>>> it. And as I said, this difference does not impact
>>>>>> interoperability from client perspective.
>>>>>>
>>>>>>
>>>>>>> Am 09.01.2020 um 00:58 schrieb Richard Backman, Annabelle
>>>>>>> <richanna=[email-masked]
>>>>>>> <mailto:[email-masked]>>:
>>>>>>>
>>>>>>> It would be more appropriate to add the text to JAR rather than
>>>>>>> PAR. It doesn't seem right for PAR to retcon rules in JAR.
>>>>>>> Moving the text to JAR also highlights the weirdness of giving
>>>>>>> PAR special treatment.
>>>>>>>  
>>>>>>> This would allow for use cases such as an AS that provides
>>>>>>> pre-defined request URIs, or vends request URIs via a client
>>>>>>> management console, or bakes them into their client apps.
>>>>>>>  
>>>>>>> – 
>>>>>>> On 1/8/20, 2:50 PM, "Torsten Lodderstedt"
>>>>>>> <torsten=[email-masked]
>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>  
>>>>>>>     Hi, 
>>>>>>>     
>>>>>>>     you are right, PAR does not require the AS to represent the
>>>>>>> request as a JWT-based request object. The URI is used as
>>>>>>> internal reference only. That why the draft states
>>>>>>>     
>>>>>>>     This difference matters from an AS implementation
>>>>>>> perspective, it doesn't matter from a client's (interop)
>>>>>>> perspective.
>>>>>>>     
>>>>>>>     We may add a statement to PAR saying that request_uris
>>>>>>> issued by the PAR mechanism (MAY) deviate from the JAR definition.
>>>>>>>     
>>>>>>>     best regards,
>>>>>>>     Torsten.  
>>>>>>>     
>>>>>>>     > On 8. Jan 2020, at 23:42, Richard Backman, Annabelle
>>>>>>> <richanna=[email-masked]
>>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>>     > 
>>>>>>>     > Hi all,
>>>>>>>     >  
>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) require that
>>>>>>> the AS transform all pushed requests into JWTs. This requirement
>>>>>>> arises from the following:
>>>>>>>     >         • PAR uses the request_uri parameter defined in
>>>>>>> JAR to communicate the pushed request to the authorization endpoint.
>>>>>>>     >         • According to JAR, the resource referenced by
>>>>>>>     >         • Request Object is defined to be a JWT containing
>>>>>>> all the authorization request parameters. (Section 2.1)
>>>>>>>     >  
>>>>>>>     > There is no need for this requirement to support
>>>>>>> interoperability, as this is internal to the AS. It is also
>>>>>>> inconsistent with the rest of JAR, which avoids attempting to
>>>>>>> define the internal communications between the two AS endpoints.
>>>>>>> Worse, this restriction makes it harder for the authorization
>>>>>>> endpoint to leverage validation and other work performed at the
>>>>>>> PAR endpoint, as the state or outcome of that work must be
>>>>>>> forced into the JWT format (or retrieved via a subsequent
>>>>>>> service call or database lookup).
>>>>>>>     >  
>>>>>>>     > – 
>>>>>>>     > Annabelle Richard Backman
>>>>>>>     > AWS Identity
>>>>>>>     >  
>>>>>>>     > _______________________________________________
>>>>>>>     > OAuth mailing list
>>>>>>>     > [email-masked] <mailto:[email-masked]>
>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>     
>>>>>>>     
>>>>> */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./*
>>>
>>> */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./*

-- 
Vladimir Dzhuvinov

---

From: Justin Richer <[email-masked]>
Date: Mon, 13 Jan 2020 12:32:41 -0500

To be clear, I’m not saying we suggest a particular form, and I agree that we shouldn’t specify that “it’s a JWT” or something of that nature. But if we call the result of PAR “thing X” and the target of request_uri “thing X” in JAR, then we’re compatible without saying what “thing X” needs to be in all cases. 

In cases where you do a remote look up, we want “thing X” to be formatted as a JWT. 

We had a case of similarly unintentional limiting in JAR previously, saying that you had to do an HTTP lookup on the request_uri, but I believe that’s been backed off now and made conditional.

 — Justin

> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> My suggestion is to abstain from specifying the concrete form of the resource pointed to by the PAR URI. Regardless of URI type (URN, downloadable https URL or something else), and even if the PAR endpoint and the authZ endpoint are managed by two different entities (microservice or other scenario).
> 
> In the Connect2id implementation of PAR the returned URI doesn't point to a request object and it doesn't point to a JWT either. It points to an internally stored "pre-processed" authZ request, which the authZ endpoint then picks up to complete the authZ.
> 
> Even if we eventually end up in microservice world, or allow the PAR endpoint to be managed by some external entity, the PAR URI - its interpretation, validation and potentially resource retrieval (JWT or other blob), is an "internal contract" on the AS side. This doesn't concern the client, and in OAuth 2.0 the role of AS is indivisible.
> 
> 
> 
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request: the client submits an authZ request and gets an authZ response at the end. The URI is necessary for the client to proceed from the 1st to the 2nd step. If we manage to frame / word the PAR URI in this logical way, without getting stuck in the JAR definition / framing of what the request_uri / object is, it would be great.
> 
> 
> 
> The normative language I think should focus on maintaining the OAuth 2.0 contract for the entire logical authZ request, together with the basic contracts of 1) JAR and the 2) authZ endpoint.
> 
> 
> 
> Vladimir
> 
> 
> 
>>> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <richanna=[email-masked] <mailto:richanna=[email-masked]>> wrote:
>>> 
>>> From: John Bradley <[email-masked] <mailto:[email-masked]>>
>>> To: Brian Campbell <[email-masked] <mailto:[email-masked]>>
>>> Cc: Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>, Nat Sakimura <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, oauth <[email-masked] <mailto:[email-masked]>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 13 Jan 2020 23:14:40 +0000

My original suggestion was to remove this requirement from cases where the AS originally provided the request_uri, because in these cases, the request_uri resolution becomes an internal implementation detail of the AS. I still think that’s the best criterion to use for when this requirement should apply. This criterion covers all JAR implementations, as the JAR endpoint is explicitly defined as being part of the AS.

Note that “AS” refers to a role within OAuth, and that role may be implemented by a collection of micro services and/or third party services. From an interop standpoint, it doesn’t matter that the PAR endpoint and authorization endpoint are hosted on separate micro services; it’s still the AS vending out a request_uri for its own consumption later. Whether that request_uri is resolved via a local DB lookup, internal web service call, or HTTP request to an S3 bucket is irrelevant.

–

From: OAuth <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Monday, January 13, 2020 at 9:33 AM
To: Vladimir Dzhuvinov <[email-masked]>
Cc: oauth <[email-masked]>, Nat Sakimura <[email-masked]>, "Richard Backman, Annabelle" <richanna=[email-masked]>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

 — Justin

On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>> wrote:

Vladimir

 — Justin

On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <richanna=[email-masked]<mailto:richanna=[email-masked]>> wrote:

From: John Bradley <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 10, 2020 at 12:29 PM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>, Nat Sakimura <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: [UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must become JWTs

John B.

John B.

To:

–

    Hi,

    best regards,
    Torsten.

OAuth mailing list

--

Vladimir Dzhuvinov

---

From: Brian Campbell <[email-masked]>
Date: Mon, 13 Jan 2020 16:19:17 -0700

+1

On Mon, Jan 13, 2020, 4:15 PM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> My original suggestion was to remove this requirement from cases where the
> AS originally provided the request_uri, because in these cases, the
> request_uri resolution becomes an internal implementation detail of the AS.
> I still think that’s the best criterion to use for when this requirement
> should apply. This criterion covers all JAR implementations, as the JAR
> endpoint is explicitly defined as being part of the AS.
>
>
>
> Note that “AS” refers to a role within OAuth, and that role may be
> implemented by a collection of micro services and/or third party services.
> From an interop standpoint, it doesn’t matter that the PAR endpoint and
> authorization endpoint are hosted on separate micro services; it’s still
> the AS vending out a request_uri for its own consumption later. Whether
> that request_uri is resolved via a local DB lookup, internal web service
> call, or HTTP request to an S3 bucket is irrelevant.
>
>
>
> –
>
> *From: *OAuth <[email-masked]> on behalf of Justin Richer <
> [email-masked]>
> *Date: *Monday, January 13, 2020 at 9:33 AM
> *To: *Vladimir Dzhuvinov <[email-masked]>
> *Cc: *oauth <[email-masked]>, Nat Sakimura <[email-masked]>, "Richard
> Backman, Annabelle" <richanna=[email-masked]>
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become JWTs
>
>
>
> To be clear, I’m not saying we suggest a particular form, and I agree that
> we shouldn’t specify that “it’s a JWT” or something of that nature. But if
> we call the result of PAR “thing X” and the target of request_uri “thing X”
> in JAR, then we’re compatible without saying what “thing X” needs to be in
> all cases.
>
>
>
> We had a case of similarly unintentional limiting in JAR previously,
> saying that you had to do an HTTP lookup on the request_uri, but I believe
> that’s been backed off now and made conditional.
>
>
>
>  — Justin
>
>
>
> downloadable https URL or something else), and even if the PAR endpoint and
> the authZ endpoint are managed by two different entities (microservice or
> other scenario).
>
> In the Connect2id implementation of PAR the returned URI doesn't point to
> a request object and it doesn't point to a JWT either. It points to an
> internally stored "pre-processed" authZ request, which the authZ endpoint
> then picks up to complete the authZ.
>
> interpretation, validation and potentially resource retrieval (JWT or other
> blob), is an "internal contract" on the AS side. This doesn't concern the
> client, and in OAuth 2.0 the role of AS is indivisible.
>
>
>
> I see PAR request + authZ request as one logical OAuth 2.0 authZ request:
> the client submits an authZ request and gets an authZ response at the end.
> The URI is necessary for the client to proceed from the 1st to the 2nd
> step. If we manage to frame / word the PAR URI in this logical way, without
> getting stuck in the JAR definition / framing of what the request_uri /
> object is, it would be great.
>
>
>
> So we could solve this by saying the resulting data object of a PAR is a
> request object. Which might also contain a request object internally as
> well. In that case JAR should back off from saying it’s a JWT and instead
> say it’s a request object. Or we define a new term for this authorization
> request blob thing.
>
>
>
> Or PAR could at least say that if it’s dereferenced over a remote protocol
> then it MUST be a JWT, but otherwise it can be whatever you want. That’s
> where the real interop concerns come in.
>
>
>
>  — Justin
>
>
>
> On Jan 10, 2020, at 3:41 PM, Richard Backman, Annabelle <
> richanna=[email-masked]> wrote:
>
>
>
> Correct. The problem becomes pretty clear in the context of PAR, where the
> AS is generating and vending out the URI at the PAR endpoint, and consuming
> it at the authorization endpoint. From an interoperability standpoint, it’s
> analogous to the AS vending an authorization code at the authorization
> endpoint and consuming it at the token endpoint.
>
> –
>
> *From: *John Bradley <[email-masked]>
> *To: *Brian Campbell <[email-masked]>
> *Cc: *Torsten Lodderstedt <[email-masked]>, Nat Sakimura <
> [email-masked]>, "Richard Backman, Annabelle" <[email-masked]>,
> oauth <[email-masked]>
> *Subject: *[UNVERIFIED SENDER] Re: [OAUTH-WG] PAR: pushed requests must
> become JWTs
>
>
>
> review, use, distribution or disclosure by others is strictly prohibited..

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 13 Jan 2020 20:46:27 -0800

> To be clear, I’m not saying we suggest a particular form, and I agree that we shouldn’t specify that “it’s a JWT” or something of that nature. But if we call the result of PAR “thing X” and the tar…

That seems fair.  What properties would a given "thing X" need to have in
order to work, though -- uniqueness over a specific period of time?
Unpredictability?  More?

-Ben

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 15 Jan 2020 22:33:15 +0200

On 13/01/2020 19:32, Justin Richer wrote:
> To be clear, I’m not saying we suggest a particular form, and I agree
> that we shouldn’t specify that “it’s a JWT” or something of that
> nature. But if we call the result of PAR “thing X” and the target of
> request_uri “thing X” in JAR, then we’re compatible without saying
> what “thing X” needs to be in all cases.

Good, we're on the same page then.

How about simply saying that the result of PAR is an URI referencing the
pushed authZ request; at the authZ endpoint its processing is completed.

No need is both clear and abstract enough to not require a form to be
specified.

> In cases where you do a remote look up, we want “thing X” to be

But why?

Both PAR and authZ endpoints belong to the AS, which makes that impl
specific. The URI is the contract, between client and AS.

The AS, if uService based, could choose to implement that as CBOR Web
Token, or some other verifiable blob, resulting in the same essential
function, and this isn't affecting the client <-> AS contract in any way.

> saying that you had to do an HTTP lookup on the request_uri, but I
> believe that’s been backed off now and made conditional.

That was precisely my point.

Vladimir

>  — Justin
>
>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> downloadable https URL or something else), and even if the PAR
>> endpoint and the authZ endpoint are managed by two different entities
>> In the Connect2id implementation of PAR the returned URI doesn't
>> point to a request object and it doesn't point to a JWT either. It
>> points to an internally stored "pre-processed" authZ request, which
>> the authZ endpoint then picks up to complete the authZ.
>>
>> request: the client submits an authZ request and gets an authZ
>> response at the end. The URI is necessary for the client to proceed
>> from the 1st to the 2nd step. If we manage to frame / word the PAR
>> URI in this logical way, without getting stuck in the JAR definition
>> / framing of what the request_uri / object is, it would be great.
>>
>>
>> The normative language I think should focus on maintaining the OAuth
>> 2.0 contract for the entire logical authZ request, together with the
>> basic contracts of 1) JAR and the 2) authZ endpoint.
>>
>>
>> Vladimir
>>
>>
>>> So we could solve this by saying the resulting data object of a PAR
>>> is a request object. Which might also contain a request object
>>> internally as well. In that case JAR should back off from saying
>>> it’s a JWT and instead say it’s a request object. Or we define a new
>>> term for this authorization request blob thing.
>>>
>>>> authorization code at the authorization endpoint and consuming it
>>>> at the token endpoint.
>>>> – 
>>>> I think I see the problem.  If the server providing the reference
>>>> is associated with the AS then the server dosen't need to
>>>> dereference the object via HTTP, so it could be a URN as an example. 
>>>>  
>>>>> Sure but the text proposed (or something like it) qualifies it
>>>>> such that there aren't interoperability questions because it's
>>>>> only an implementation detail to the AS who both produces the URI
>>>>> and consumes its content.
>>>>>  
>>>>>>> Agree and agree. But given that the change suggested by
>>>>>>> Annabelle has no impact on the client or interoperability,
>>>>>>> perhaps Nat or John could work the change into the draft during
>>>>>>> the edits that happen during the final stages of things?
>>>>>>>  
>>>>>>>>> It would be more appropriate to add the text to JAR rather
>>>>>>>>> than PAR. It doesn't seem right for PAR to retcon rules in
>>>>>>>>> JAR. Moving the text to JAR also highlights the weirdness of
>>>>>>>>> giving PAR special treatment.
>>>>>>>>>  
>>>>>>>>>     you are right, PAR does not require the AS to represent
>>>>>>>>> the request as a JWT-based request object. The URI is used as
>>>>>>>>>     > The current drafts of PAR (-00) and JAR (-20) require
>>>>>>>>> that the AS transform all pushed requests into JWTs. This
>>>>>>>>> requirement arises from the following:
>>>>>>>>>     >         • Request Object is defined to be a JWT
>>>>>>>>> containing all the authorization request parameters. (Section 2.1)
>>>>>>>>>     >  
>>>>>>>>> define the internal communications between the two AS
>>>>>>>>> endpoints. Worse, this restriction makes it harder for the
>>>>>>>>> authorization endpoint to leverage validation and other work
>>>>>>>>> performed at the PAR endpoint, as the state or outcome of that
>>>>>>>>> work must be forced into the JWT format (or retrieved via a
>>>>>>>>> subsequent service call or database lookup).
>>>>>>>>>     >  
>>>>>>>>>     > – 
>>>>>>> */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./*
>>>>>
-- 
Vladimir Dzhuvinov

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 15 Jan 2020 22:43:26 +0200

> order to work, though -- uniqueness over a specific period of time?

 1. That the request_uri uniquely points to the submitted authZ request
    for the duration of the request_uri lifetime (defined by the
    expires_in response parameter).
 2. The request_uri cannot be reasonably guessed.

I think that's all we need Ben.

Vladimir

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 16 Jan 2020 01:30:31 +0000

The problem is the JWT requirement in JAR, not how we talk about PAR request_uri values in PAR. We need to either change the language in JAR (see my suggestions elsewhere in this thread), or add text in PAR that explicitly exempts PAR request_uri values (or preferably all AS-provided request_uri values) from this requirement (also see my suggestions elsewhere in this thread).

My preference remains the former. It strikes me as bad form for one extension to override normative requirements laid out in another document. Granted, the incompatibility scenarios introduced by this retcon are edge-case at best, but that just raises the question of why we can’t fix the draft that hasn’t actually been published yet.

–

From: OAuth <[email-masked]> on behalf of Vladimir Dzhuvinov <[email-masked]>
Organization: Connect2id Ltd.
Date: Wednesday, January 15, 2020 at 12:34 PM
To: Justin Richer <[email-masked]>
Cc: oauth <[email-masked]>, Nat Sakimura <[email-masked]>, "Richard Backman, Annabelle" <richanna=[email-masked]>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

How about simply saying that the result of PAR is an URI referencing the pushed authZ request; at the authZ endpoint its processing is completed.

No need is both clear and abstract enough to not require a form to be specified.

But why?

Both PAR and authZ endpoints belong to the AS, which makes that impl specific. The URI is the contract, between client and AS.

The AS, if uService based, could choose to implement that as CBOR Web Token, or some other verifiable blob, resulting in the same essential function, and this isn't affecting the client <-> AS contract in any way.

Vladimir

 — Justin

Vladimir

 — Justin

John B.

John B.

To:

–

    Hi,

    best regards,
    Torsten.

OAuth mailing list

--

Vladimir Dzhuvinov

--

Vladimir Dzhuvinov

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 10:47:08 -0500

+1 to this approach, and it sounds like JAR might need to come back to go through another round anyway thanks to the breaking changes the IESG pushed into it after it left WGLC.

I’d rather see us get this right than publish something many of us think is broken. 

Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.

 — Justin

> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> From: OAuth <[email-masked] <mailto:[email-masked]>> on behalf of Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>>
>>> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
>>>  
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>-- 
>>> Vladimir Dzhuvinov
>> 
>>  
> -- 
> Vladimir Dzhuvinov

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jan 2020 17:25:13 +0100

I just thought about another option. What if we change PAR to not use the request_uri parameter but a new parameter, e.g. request_id?

That would decouple both specs. The reason why we use request_uri was to make the life of clients easier since they can use the standard library function for request objects to pass the PAR reference to the AS. Is this worth the trouble?

> Am 16.01.2020 um 16:48 schrieb Justin Richer <[email-masked]>:
> 
>>>>>>> On Fri, Jan 10, 2020, 4:57 PM Brian Campbell <[email-masked]> wrote:
>>>>>>>>> On Fri, Jan 10, 2020, 3:45 PM Brian Campbell <[email-masked]> wrote:
>>>>>>>>>> On Thu, Jan 9, 2020 at 1:56 AM Torsten Lodderstedt <torsten=[email-masked]> wrote:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 16 Jan 2020 17:28:14 +0100

> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.

Since Justin brought it up, I would like to know whether the community has appetite to standardize JARM as well.

Here is the link to the spec: https://openid.net/specs/openid-financial-api-jarm-ID1.html

What do you think?

---

From: Neil Madden <[email-masked]>
Date: Thu, 16 Jan 2020 16:36:59 +0000

Why not have the PAR endpoint return a 30x redirect with the full URL to the authorization endpoint in the Location header? That way the AS can decide for itself how to communicate any id from the PAR endpoint to the authorization endpoint.

This also has the side effect that you can kick off an OAuth2 flow with a simple HTML form pointed at the PAR endpoint (with hidden fields for state/code_challenge etc).

If actually performing the redirect is a bit problematic then at least the idea of returning a full URL for the authorization endpoint (hyperlink) rather than returning an id/URI and requiring the client to construct one seems reasonable to me and would seem to avoid some of the difficulties being discussed with JAR etc as the exact mechanism of communication becomes an implementation detail that the client needn't know about.

-- Neil

> On 16 Jan 2020, at 16:25, Torsten Lodderstedt <torsten=[email-masked]> wrote:
> 
>>> On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Organization: Connect2id Ltd..
>>> To: Justin Richer <[email-masked] <mailto:[email-masked]>>
>>> Cc: oauth <[email-masked] <mailto:[email-masked]>>, Nat Sakimura <[email-masked] <mailto:[email-masked]>>, "Richard Backman, Annabelle" <richanna=[email-masked] <mailto:richanna=[email-masked]>>
>>>>>>>>>>>>     > OAuth@ietf..org <mailto:[email-masked]>
>>>>>> OAuth@ietf..org <mailto:[email-masked]>

---

From: Filip Skokan <[email-masked]>
Date: Thu, 16 Jan 2020 17:40:30 +0100

Thinking of all the new edge cases we'd have to cover, i don't believe its
a good idea, as-is i see it elegant, capable of re-using existing
pipelines, the moment you change the parameter name new edge cases and
conditions start to popup. As an implementer i don't care that JAR says the
request_uri must reference a JWT, i know that requirement is in place for
the client<>AS contract. I'm fine with a language lifting that particular
requirement being present in PAR but i see that as a nitpick that adds
little to no real value to the final specification.

S pozdravem,
*Filip Skokan*

On Thu, 16 Jan 2020 at 17:25, Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> I just thought about another option. What if we change PAR to not use the
> request_uri parameter but a new parameter, e.g. request_id?
>
> That would decouple both specs. The reason why we use request_uri was to
> make the life of clients easier since they can use the standard library
> function for request objects to pass the PAR reference to the AS. Is this
> worth the trouble?
>
> +1 to this approach, and it sounds like JAR might need to come back to go
> through another round anyway thanks to the breaking changes the IESG pushed
> into it after it left WGLC.
>
> The problem is the JWT requirement in JAR, not how we talk about PAR
> request_uri values in PAR. We need to either change the language in JAR
> (see my suggestions elsewhere in this thread), or add text in PAR that
> explicitly exempts PAR request_uri values (or preferably all AS-provided
> request_uri values) from this requirement (also see my suggestions
> elsewhere in this thread).
>
> My preference remains the former. It strikes me as bad form for one
> extension to override normative requirements laid out in another document.
> Granted, the incompatibility scenarios introduced by this retcon are
> edge-case at best, but that just raises the question of why we can’t fix
> the draft that hasn’t actually been published yet.
>
> –
> *From: *OAuth <[email-masked]> on behalf of Vladimir Dzhuvinov <
> [email-masked]>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer <[email-masked]>
>     > OAuth@ietf..org <[email-masked]>
> OAuth@ietf..org <[email-masked]>
>

---

From: Dave Tonge <[email-masked]>
Date: Thu, 16 Jan 2020 17:41:34 +0100

I like that idea - although not the 301. But returning the full url seems
like a good idea.
Most of the time PAR will be used on the backend and the user-agent won't
be directly submitting a form - so for the most common use-case a 301 would
cause problems.

On Thu, 16 Jan 2020 at 17:37, Neil Madden <[email-masked]> wrote:

> Why not have the PAR endpoint return a 30x redirect with the full URL to
> the authorization endpoint in the Location header? That way the AS can
> decide for itself how to communicate any id from the PAR endpoint to the
> authorization endpoint.
>
> This also has the side effect that you can kick off an OAuth2 flow with a
> simple HTML form pointed at the PAR endpoint (with hidden fields for
> state/code_challenge etc).
>
> If actually performing the redirect is a bit problematic then at least the
> idea of returning a full URL for the authorization endpoint (hyperlink)
> rather than returning an id/URI and requiring the client to construct one
> seems reasonable to me and would seem to avoid some of the difficulties
> being discussed with JAR etc as the exact mechanism of communication
> becomes an implementation detail that the client needn't know about.
>
> -- Neil
>
> On 16 Jan 2020, at 16:25, Torsten Lodderstedt <
> torsten=[email-masked]> wrote:
>

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

---

From: Filip Skokan <[email-masked]>
Date: Thu, 16 Jan 2020 17:44:02 +0100

A 30x redirect to what is designed to be an authenticated backend client
call? Doesn't seem right to me.

S pozdravem,
*Filip Skokan*

---

From: Neil Madden <[email-masked]>
Date: Thu, 16 Jan 2020 17:13:21 +0000

Well I don't think PAR is limited to confidential clients, but also there are client authentication methods that would make sense in this scenario, e.g. JWT-based client_assertion authentication with a short-lived/replay-protected JWT.

This cuts out the need for an extra HTTP call on the server side. The trade-off is that the parameters can still be tampered with in the user-agent, but you still get the other benefits listed in the PAR draft:
- The client is authenticated up-front before the user authorization is performed
- The authorization request parameters are not exposed in URL query strings (in logs, Referer headers etc)
- Any size restrictions on query parameters are avoided

I'm not 100% convinced myself that a redirect is a good idea, but if the AS is exposing an endpoint that accepts POST requests with form-encoded parameters, then as a developer it seems perfectly reasonable to expect to be able to post a form to it. Maybe we could make that do something useful? If the intention is to rule out this kind of usage, then perhaps the payload should be defined to be JSON.

-- Neil

> On 16 Jan 2020, at 16:44, Filip Skokan <[email-masked]> wrote:
> 
> A 30x redirect to what is designed to be an authenticated backend client call? Doesn't seem right to me.
> 
> S pozdravem,
> Filip Skokan
> 
> 
> On Thu, 16 Jan 2020 at 17:37, Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
>> On 16 Jan 2020, at 16:25, Torsten Lodderstedt <torsten=[email-masked] <mailto:torsten=[email-masked]>> wrote:
>> 
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer <[email-masked] <mailto:[email-masked]>>:
>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 16 Jan 2020 12:33:19 -0500

What you’ve described is exactly what happens in XYZ:

https://oauth.xyz/interaction/

And this is what we’re discussing as the basis in TxAuth. But in this case since you’re stuck with OAuth 2’s authorization endpoint syntax and semantics, you’re still limited with what’s happening there and it could come with its own security oddities (like maybe a new form of a mixup attack?) that we haven’t figured out yet. Like, is the AS allowed to send the client to something other than its own authorization endpoint? Is the client supposed to validate the syntax of the authorization endpoint URL against its discovery document? It deeply changes what OAuth 2 does, and that makes it really hard to add on.

Using request_uri to pass the artifact is clever, but I also like Torsten’s idea of using a new field defined by PAR to pass the artifact. Granted, in the Authlete implementation of PAR, we were able to re-use a whole bunch of code for processing request objects, and that was pretty nice. Still, the issues with JAR are non-zero, and so we need to figure out whether we should fully decouple or fix the issues. I’m in favor of fixing things and using these together, but there’s a lot of inertia against that.

 — Justin

> On Jan 16, 2020, at 11:36 AM, Neil Madden <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 16 Jan 2020 17:49:03 +0000

We’ve already defined a request identifier parameter. We called it “request_uri”. That’s what the “I” in URI stands for. Let’s just fix the semantics on that one. It’s bad enough that we have request and request_uri, let’s not add a third one.

Sent from my iPhone

On Jan 16, 2020, at 9:33 AM, Justin Richer <[email-masked]> wrote:

 — Justin

On Jan 16, 2020, at 11:36 AM, Neil Madden <[email-masked]<mailto:[email-masked]>> wrote:

-- Neil

On 16 Jan 2020, at 16:25, Torsten Lodderstedt <torsten=[email-masked]<mailto:torsten=[email-masked]>> wrote:

Am 16.01.2020 um 16:48 schrieb Justin Richer <[email-masked]<mailto:[email-masked]>>:

 — Justin

On Jan 15, 2020, at 8:30 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

–

From: OAuth <[email-masked]<mailto:[email-masked]>> on behalf of Vladimir Dzhuvinov <[email-masked]<mailto:[email-masked]>>
Organization: Connect2id Ltd..
Date: Wednesday, January 15, 2020 at 12:34 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>, Nat Sakimura <[email-masked]<mailto:[email-masked]>>, "Richard Backman, Annabelle" <richanna=[email-masked]<mailto:richanna=[email-masked]>>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

 — Justin

Vladimir

 — Justin

John B.

John B.

To:

–

    Hi,

    best regards,
    Torsten.

    > OAuth@ietf..org<mailto:[email-masked]>

OAuth mailing list

OAuth@ietf..org<mailto:[email-masked]>

--

Vladimir Dzhuvinov

--

Vladimir Dzhuvinov

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Jan 2020 12:47:41 -0700

+1 to keeping/using “request_uri”

On Thu, Jan 16, 2020 at 10:49 AM Richard Backman, Annabelle <richanna=
[email-masked]> wrote:

> We’ve already defined a request identifier parameter. We called it
> “request_uri”. That’s what the “I” in URI stands for. Let’s just fix the
> semantics on that one. It’s bad enough that we have request and
> request_uri, let’s not add a third one.
>
> Sent from my iPhone
>
> And this is what we’re discussing as the basis in TxAuth. But in this case
> since you’re stuck with OAuth 2’s authorization endpoint syntax and
> semantics, you’re still limited with what’s happening there and it could
> come with its own security oddities (like maybe a new form of a mixup
> attack?) that we haven’t figured out yet. Like, is the AS allowed to send
> the client to something other than its own authorization endpoint? Is the
> client supposed to validate the syntax of the authorization endpoint URL
> against its discovery document? It deeply changes what OAuth 2 does, and
> that makes it really hard to add on.
>
> Using request_uri to pass the artifact is clever, but I also like
> Torsten’s idea of using a new field defined by PAR to pass the artifact.
> Granted, in the Authlete implementation of PAR, we were able to re-use a
> whole bunch of code for processing request objects, and that was pretty
> nice. Still, the issues with JAR are non-zero, and so we need to figure out
> whether we should fully decouple or fix the issues. I’m in favor of fixing
> things and using these together, but there’s a lot of inertia against that.
>
>  — Justin
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 17 Jan 2020 13:21:21 -0700

I'd be in favor of it.

On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> Here is the link to the spec:
> https://openid.net/specs/openid-financial-api-jarm-ID1.html
>
> What do you think?

---

From: Takahiko Kawasaki <[email-masked]>
Date: Thu, 23 Jan 2020 15:03:07 +0900

I think that JARM is good and even feel that JARM should exist there from a
logical perspective because JARM is to Authorization Response what Request
Object is to Authorization Request. It is good that we don't have to use
"ID Token as Detached Signature" (Financial-grade API Part 2) when JARM is
used.

FWIW, I (Authlete) finished implementing JARM at the beginning of October,
2018, about a year and 3 months ago.

Best Regards,
Takahiko Kawasaki

On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

>> Since Justin brought it up, I would like to know whether the community
>> has appetite to standardize JARM as well.
>>
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: Neil Madden <[email-masked]>
Date: Thu, 23 Jan 2020 07:03:02 +0000

If you’re using auth code and PKCE, what does JARM add?

Neil

> On 23 Jan 2020, at 06:03, Takahiko Kawasaki <[email-masked]> wrote:
> 
> 
> I think that JARM is good and even feel that JARM should exist there from a logical perspective because JARM is to Authorization Response what Request Object is to Authorization Request. It is good that we don't have to use "ID Token as Detached Signature" (Financial-grade API Part 2) when JARM is used.
> 
> FWIW, I (Authlete) finished implementing JARM at the beginning of October, 2018, about a year and 3 months ago.
> 
> Best Regards,
> Takahiko Kawasaki
> 
>> On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell <bcampbell=[email-masked]> wrote:
>> I'd be in favor of it. 
>> 
>>> On Thu, Jan 16, 2020 at 9:28 AM Torsten Lodderstedt <torsten=[email-masked]> wrote:
>>> 
>>> 
>> 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
>> [email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 24 Jan 2020 12:04:55 +0900

Excellent question. Since the authorisation response contains that code only in this case, one basically gains sender authentication and non-repudiation.

> On 23. Jan 2020, at 16:03, Neil Madden <[email-masked]> wrote:
> 
>> On Sat, Jan 18, 2020 at 5:22 AM Brian Campbell <bcampbell=[email-masked]> wrote:
>> I'd be in favor of it. 
>>