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> 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> 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> >> 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> 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>: >>>> >>>> >>>> >>>> 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> 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> 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 >>>> >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> 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
