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 <neil.mad...@forgerock.com> 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=40lodderstedt....@dmarc.ietf.org> 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 <jric...@mit.edu>: > > +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 < > richa...@amazon.com> 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 <oauth-boun...@ietf.org> on behalf of Vladimir Dzhuvinov < > vladi...@connect2id.com> > *Organization: *Connect2id Ltd.. > *Date: *Wednesday, January 15, 2020 at 12:34 PM > *To: *Justin Richer <jric...@mit.edu> > *Cc: *oauth <oauth@ietf.org>, Nat Sakimura <n...@sakimura.org>, "Richard > Backman, Annabelle" <richanna=40amazon....@dmarc.ietf.org> > *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 <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> 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> > 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 > > oa...@ietf..org <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 > > > > > _______________________________________________ > > OAuth mailing list > > oa...@ietf..org <OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Vladimir Dzhuvinov > > > > -- > > Vladimir Dzhuvinov > > > _______________________________________________ > 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 > > > _______________________________________________ > 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
