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
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
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
the draft that hasn’t actually been published yet.
>>>>
>>>> –
>>>> Annabelle Richard Backman
>>>> AWS Identity
>>>>
>>>>
>>>> From: OAuth mailto:oauth-boun...@ietf.org>> on
>>>> behalf of Vl
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.
>>>>
>>>> –
>>>> Annabelle Richard Backman
>>>> A
t;
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth on behalf of Vladimir Dzhuvinov <
> vladi...@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer
> *Cc: *oauth , Na
ase at best, but that just raises the question of why we can’t fix
> the draft that hasn’t actually been published yet.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth on behalf of Vladimir Dzhuvinov <
> vladi...@connect2id.com>
> *Organiz
hed yet.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth on behalf of Vladimir Dzhuvinov <
> vladi...@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer
> *Cc: *oauth
>>>
>>> From: OAuth mailto:oauth-boun...@ietf.org>> on
>>> behalf of Vladimir Dzhuvinov >> <mailto:vladi...@connect2id.com>>
>>> Organization: Connect2id Ltd..
>>> Date: Wednesday, January 15, 2020 at 12:34 PM
>>> To:
; Annabelle Richard Backman
>> AWS Identity
>>
>>
>> From: OAuth on behalf of Vladimir Dzhuvinov
>>
>> Organization: Connect2id Ltd.
>> Date: Wednesday, January 15, 2020 at 12:34 PM
>> To: Justin Richer
>> Cc: oauth , Nat Sakimur
15, 2020 at 12:34 PM
> To: Justin Richer
> Cc: oauth , Nat Sakimura , "Richard
> Backman, Annabelle"
> Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must
> become JWTs
>
> On 13/01/2020 19:32, Justin Richer wrote:
>> To be clear, I’m n
On 14/01/2020 06:46, Benjamin Kaduk wrote:
> On Mon, Jan 13, 2020 at 12:32:41PM -0500, 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
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
On Mon, Jan 13, 2020 at 12:32:41PM -0500, 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”
behalf of Justin Richer <
> jric...@mit.edu>
> *Date: *Monday, January 13, 2020 at 9:33 AM
> *To: *Vladimir Dzhuvinov
> *Cc: *oauth , Nat Sakimura , "Richard
> Backman, Annabelle"
> *Subject: *Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests
> must become
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
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
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
18 matches
Mail list logo
