Aaron,
The “request_uri” comes from OIDC originally, and is redefined in JAR. The
original idea was to have a URL that the AS/IdP would be able to fetch to get a
Request Object from, which is why JAR used to have language about “it MUST be
fetchable and resolve to a JWT” (or something like that). JAR has backed off
that requirement now (I believe), but those roots are still in the name. RAR
opts to re-use that mechanism instead of inventing either a new parameter or
returning a full Redirection URI.
— Justin
> On Jul 24, 2020, at 3:12 AM, Torsten Lodderstedt
> <torsten=40lodderstedt....@dmarc.ietf.org> wrote:
>
> Hi Aaron,
>
> that’s a very good point. I was also in favour of just providing the client
> with the URL it needs to send the user to (like XYZ and OAuth do).
>
> In the end, we decided to stay with the current approach since it fits with
> the rest of the existing ecosystem, namely JAR and authorization endpoint
> discovery.
>
> best regards,
> Torsten.
>
>> On 24. Jul 2020, at 00:49, Aaron Parecki <aa...@parecki.com> wrote:
>>
>> I know this is a bit of an old thread to dig up, but as I'm working through
>> this draft again, something is sticking out to me about this.
>>
>> In every other instance of "*_uri" in OAuth and extensions, the value is a
>> URI (usually https) which will be visited by the user's browser or be sent a
>> POST request from a client. In the case of PAR, this "request_uri" is
>> actually just an identifier that is *added* to an existing URL, the
>> authorization endpoint, not a URL that will be visited itself. This
>> discrepancy is bothering me.
>>
>> I would have expected that either:
>>
>> * The PAR response includes a "request_uri" which is the full URL that the
>> client would redirect the user's browser to, OR
>> * The PAR response includes a "request_id" which it adds in the query string
>> to the authorization endpoint and then redirects the browser to
>>
>> For example:
>>
>> POST /as/par HTTP/1.1
>> ...
>> response:
>> {
>> "request_uri":
>> "https://as.example.com/auth?request=bwc4JK-ESC0w8acc191e-Y1LTC2";,
>> "expires_in": 60
>> }
>>
>> then the user's browser is sent to whatever the value of "request_uri" is
>>
>> OR
>>
>> POST /as/par HTTP/1..1
>> ...
>> response:
>> {
>> "request_id":
>> "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
>> "expires_in": 60
>> }
>>
>> then the "request_id" is added to the authorization endpoint (as currently
>> described by PAR)
>>
>> https://as.example.com/auth?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2
>>
>> My personal preference is the first option, keeping the term "request_uri"
>> but having it actually be the full URI, to simplify the job of the client.
>> In that model, the client doesn't have to mess with building URLs, and
>> actually provides additional flexibility for the AS as well since that
>> endpoint no longer needs to be the exact same URL as the authorization
>> endpoint..
>>
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>>
>>
>> On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt
>> <torsten=40lodderstedt....@dmarc.ietf.org> 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?
>>
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer <jric...@mit.edu>:
>>>
>>> +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
>>>
>>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
