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

[Vladimir Dzhuvinov <[e-mail]>]

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=[e-mail]
>> <mailto:richanna=[e-mail]>> 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.
>> – 
>> Annabelle Richard Backman
>> AWS Identity
>>  
>>  
>> *From: *John Bradley <[e-mail] <mailto:[e-mail]>>
>> *Date: *Friday, January 10, 2020 at 12:29 PM
>> *To: *Brian Campbell <[e-mail]
>> <mailto:[e-mail]>>
>> *Cc: *Torsten Lodderstedt <[e-mail]
>> <mailto:[e-mail]>>, Nat Sakimura <[e-mail]
>> <mailto:[e-mail]>>, "Richard Backman, Annabelle"
>> <[e-mail] <mailto:[e-mail]>>, oauth
>> <[e-mail] <mailto:[e-mail]>>
>> *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. 
>>  
>> 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
>> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>>> <mailto:[e-mail]>> 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
>>>> <[e-mail] <mailto:[e-mail]>> 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=[e-mail]
>>>>> <mailto:[e-mail]>> 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=[e-mail]
>>>>>>> <mailto:[e-mail]>>:
>>>>>>>
>>>>>>> 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=[e-mail]
>>>>>>> <mailto:[e-mail]>> 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=[e-mail]
>>>>>>> <mailto:[e-mail]>> 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
>>>>>>>     > [e-mail] <mailto:[e-mail]>
>>>>>>>     > https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>     
>>>>>>>     
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> 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./*
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Vladimir Dzhuvinov