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

[Filip Skokan <[e-mail]>]

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 <[e-mail]> 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=[e-mail]> 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 <[e-mail]>:
>
> +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 <
> [e-mail]> wrote:
>
> 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.
>
> –
> Annabelle Richard Backman
> AWS Identity
>
>
> *From: *OAuth <[e-mail]> on behalf of Vladimir Dzhuvinov <
> [e-mail]>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer <[e-mail]>
> *Cc: *oauth <[e-mail]>, Nat Sakimura <[e-mail]>, "Richard
> Backman, Annabelle" <richanna=[e-mail]>
> *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 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 formatted
> as a JWT.
>
> 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.
>
>
> 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.
>
> That was precisely my point.
> Vladimir
>
>
>
>  — Justin
>
>
> On Jan 11, 2020, at 5:28 AM, Vladimir Dzhuvinov <[e-mail]>
> 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 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]> 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]>
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell <[e-mail]>
> *Cc: *Torsten Lodderstedt <[e-mail]>, Nat Sakimura <
> [e-mail]>, "Richard Backman, Annabelle" <[e-mail]>,
> oauth <[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]>
> 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]> 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]>
> 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]> 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]>:
>
> 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]> 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]> 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
>     > OAuth@ietf..org <[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [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]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf..org <[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Vladimir Dzhuvinov
>
>
>
> --
>
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>