Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

Brian Campbell <bcampbell@pingidentity.com> Fri, 17 January 2020 19:48 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09E1200A4 for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2020 11:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmLXNCKthGQk for <oauth@ietfa.amsl.com>; Fri, 17 Jan 2020 11:48:12 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349121200D6 for <oauth@ietf.org>; Fri, 17 Jan 2020 11:48:11 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id r19so27654546ljg.3 for <oauth@ietf.org>; Fri, 17 Jan 2020 11:48:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G2lOItU26xjK2QAiuDwcmVBjdhg/5+KDhFxznyq6iws=; b=E4bYK5mFO7KI81f8c5BbCnNFdBQch0kscmtH48lFZ9iuVRjyS6HxHT011UGdo3GbE5 BQ3UJpVCV8rBCW8JSDtRE9oI9LWxbrYbwTsmC8wBlC8/yjVnc9r9QXu7ptx34zNX0rsm De0zOgzZQtxbQnU6dQfG/s5QfX8kS42ry21aKHte7A/xNyVcwcTbrm1BfTnDyAJ5otc0 35XylkSlCHsdXbX29sLYiNfS/OAn6QejQ4Rr6ELk57swu58ug2Bl04kg1CoywUOS1n/5 ZYBBi7Cvtf8rqRKjRXhKcNRhJm3YLa3KnGxCXzItcZ7+DuNqzwlkkRrfCfKd+Ad0wgxi LsiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G2lOItU26xjK2QAiuDwcmVBjdhg/5+KDhFxznyq6iws=; b=clyU9UMbRKL34UYBJjBEDdc+CQWy9YENScHCxw8Z5XnSOCQKnQNbcJyukk4olRsCpJ j8skh1dIjwxJ+tZFXM6r+FbG7W3K7BzPHedqIOwRQxwFQI/U8mCRleVrSFTZmwS5t2eS SL3+tGBbYDEQoshJSHvbHTm+rAWEpuAdmFUXPxC77wiKX6GcYNBcIId7968q1RTzK3nU 7Hkb5Gfocq4cfa4xCkP9p8tYDKtipp1RDWr5hh7azpDtXFKuVMRTCPSDI0JGk6d8gPlB QnREZAuUN4AvadXuMPPQh/F/Rd5xB2nmT5yDSIWjQSJ7k64OhwCMwwiCQKnRNw+8jaSe vk5g==
X-Gm-Message-State: APjAAAXmEGpialLfeoitGzQbw2cFE6ZcWrk1vdHIbpcraZ5+fyBh5EpS 3lu+WGFpmlx3q79vLejGDlpzbhVtz7lN5ExJT5DDfNXRLGcyPQ7hW1SdtFdA2CPRCIJWhngyJbQ Hi67lCab/dCtu5Q==
X-Google-Smtp-Source: APXvYqzjqkNdT2N/ECVm1ZH/MIkj29FCU1vhoPiteZJezmWHFpSDg99Xn/vr1R0FShmNb3Zg7LKm5E5mrjFw7j4osAU=
X-Received: by 2002:a2e:805a:: with SMTP id p26mr6622323ljg.242.1579290489274; Fri, 17 Jan 2020 11:48:09 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net> <6773E3CE-4328-4060-91CD-85B1E159B631@forgerock.com> <F4429635-8F67-42DE-BE15-08B8FC0D412E@mit.edu> <00807967-2452-4DB0-AF0C-5BE7EA92B3A7@amazon.com>
In-Reply-To: <00807967-2452-4DB0-AF0C-5BE7EA92B3A7@amazon.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 17 Jan 2020 12:47:41 -0700
Message-ID: <CA+k3eCS_ewSUQ_tE+PC7dYdsxULJ1afV9CPR9Wdph4u0MACHOQ@mail.gmail.com>
To: "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Cc: Justin Richer <jricher@mit.edu>, Nat Sakimura <nat@sakimura.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009c5fe1059c5b382d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RlmPrlHTk-_qErNKbB42QAFtasc>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 19:48:15 -0000

+1 to keeping/using “request_uri”

On Thu, Jan 16, 2020 at 10:49 AM Richard Backman, Annabelle <richanna=
40amazon.com@dmarc.ietf.org> wrote:

> We’ve already defined a request identifier parameter. We called it
> “request_uri”. That’s what the “I” in URI stands for. Let’s just fix the
> semantics on that one. It’s bad enough that we have request and
> request_uri, let’s not add a third one.
>
> Sent from my iPhone
>
> On Jan 16, 2020, at 9:33 AM, Justin Richer <jricher@mit.edu> wrote:
>
>  What you’ve described is exactly what happens in XYZ:
>
> https://oauth.xyz/interaction/
>
> And this is what we’re discussing as the basis in TxAuth. But in this case
> since you’re stuck with OAuth 2’s authorization endpoint syntax and
> semantics, you’re still limited with what’s happening there and it could
> come with its own security oddities (like maybe a new form of a mixup
> attack?) that we haven’t figured out yet. Like, is the AS allowed to send
> the client to something other than its own authorization endpoint? Is the
> client supposed to validate the syntax of the authorization endpoint URL
> against its discovery document? It deeply changes what OAuth 2 does, and
> that makes it really hard to add on.
>
> Using request_uri to pass the artifact is clever, but I also like
> Torsten’s idea of using a new field defined by PAR to pass the artifact.
> Granted, in the Authlete implementation of PAR, we were able to re-use a
> whole bunch of code for processing request objects, and that was pretty
> nice. Still, the issues with JAR are non-zero, and so we need to figure out
> whether we should fully decouple or fix the issues. I’m in favor of fixing
> things and using these together, but there’s a lot of inertia against that.
>
>  — Justin
>
> On Jan 16, 2020, at 11:36 AM, Neil Madden <neil.madden@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.net@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 <jricher@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 <
> richanna@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-bounces@ietf.org> on behalf of Vladimir Dzhuvinov <
> vladimir@connect2id.com>
> *Organization: *Connect2id Ltd..
> *Date: *Wednesday, January 15, 2020 at 12:34 PM
> *To: *Justin Richer <jricher@mit.edu>
> *Cc: *oauth <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard
> Backman, Annabelle" <richanna=40amazon.com@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 <vladimir@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.com@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 <ve7jtb@ve7jtb.com>
> *Date: *Friday, January 10, 2020 at 12:29 PM
> *To: *Brian Campbell <bcampbell@pingidentity.com>
> *Cc: *Torsten Lodderstedt <torsten@lodderstedt.net>, Nat Sakimura <
> nat@sakimura.org>, "Richard Backman, Annabelle" <richanna@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 <bcampbell@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 <ve7jtb@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 <bcampbell@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.net@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.com@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.net@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.com@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 <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
>
> OAuth@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
>

-- 
_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._