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