Thanks for the text proposal. It works for me.
> Am 09.01.2020 um 20:34 schrieb Richard Backman, Annabelle > <[email protected]>: > > > If we address this in PAR, I suggest something along the lines of the > following: > > As defined in [JAR], the request_uri parameter is required to reference a > Request Object JWT. An AS MAY violate this requirement when it is generating > request URIs intended for its own consumption (e.g., URIs for pushed > requests). This requirement exists to ensure interoperability in cases where > the provider of the request_uri is a separate entity from the consumer, such > as when a client provides a URI referencing an object stored on the client’s > backend service. When the AS is both provider and consumer, this > interoperability concern does not apply. > > – > Annabelle Richard Backman > AWS Identity > > > From: OAuth <[email protected]> on behalf of Torsten Lodderstedt > <[email protected]> > Date: Thursday, January 9, 2020 at 12:56 AM > To: "Richard Backman, Annabelle" <[email protected]> > Cc: oauth <[email protected]> > Subject: Re: [OAUTH-WG] PAR: pushed requests must become JWTs > > 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 > <[email protected]>: > > 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" > <[email protected]> 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 > <[email protected]> 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
