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 <vladi...@connect2id.com> > 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=40amazon....@dmarc.ietf.org >>> <mailto:richanna=40amazon....@dmarc.ietf.org>> 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 <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> >>> Date: Friday, January 10, 2020 at 12:29 PM >>> To: Brian Campbell <bcampb...@pingidentity.com >>> <mailto:bcampb...@pingidentity.com>> >>> Cc: Torsten Lodderstedt <tors...@lodderstedt.net >>> <mailto:tors...@lodderstedt.net>>, Nat Sakimura <n...@sakimura.org >>> <mailto:n...@sakimura.org>>, "Richard Backman, Annabelle" >>> <richa...@amazon.com <mailto:richa...@amazon.com>>, oauth <oauth@ietf.org >>> <mailto:oauth@ietf.org>> >>> 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 <bcampb...@pingidentity.com >>> <mailto:bcampb...@pingidentity.com>> 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 <ve7...@ve7jtb.com >>>> <mailto:ve7...@ve7jtb.com>> 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 <bcampb...@pingidentity.com >>>>> <mailto:bcampb...@pingidentity.com>> 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=40lodderstedt....@dmarc.ietf.org >>>>>> <mailto:40lodderstedt....@dmarc.ietf.org>> 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=40amazon....@dmarc.ietf.org >>>>>>>> <mailto:40amazon....@dmarc.ietf.org>>: >>>>>>>> >>>>>>>> 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=40lodderstedt....@dmarc.ietf.org >>>>>>>> <mailto:40lodderstedt....@dmarc.ietf.org>> 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=40amazon....@dmarc.ietf.org >>>>>>>> <mailto:40amazon....@dmarc.ietf.org>> 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 <mailto:OAuth@ietf.org> >>>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <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 >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > -- > Vladimir Dzhuvinov
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
