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

Filip Skokan <panva.ip@gmail.com> Thu, 16 January 2020 16:40 UTC

Return-Path: <panva.ip@gmail.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 D3EF91209A1 for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 08:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 bHiyvuvSH1vp for <oauth@ietfa.amsl.com>; Thu, 16 Jan 2020 08:40:42 -0800 (PST)
Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 823FE12004C for <oauth@ietf.org>; Thu, 16 Jan 2020 08:40:42 -0800 (PST)
Received: by mail-yw1-xc2d.google.com with SMTP id i126so12993884ywe.7 for <oauth@ietf.org>; Thu, 16 Jan 2020 08:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tnqi9Z9gofsBQXA82sqVpawhYp8WofiFpp2PlYl/4bY=; b=vXzZz5PfVxmeQYKIRdABi9ivzx0iz2vF/xADTWXNiinIXYjdxtc0BN9WSK5/IJ4C+T HIvniBXBitAmrxbigb3FIde2GZAcp3f1Kkd4Utom1khNlhkyxqCYvYsPz8lpxT3Ecpwh v3102QN5/fHBpEETaCqifRETUsYzoFY2ipX7lpYhi9rmqidgtRZbERTVKuu1k5FzdnFO UdBeilsmKRjVma9/StjAOcAZPj36NBWJ+86GjUdJYyxyBsCDddzOceeSTFimhACeTFhY cG4zckhSwud+kbm2YsHufmo+h91RgAwyW5DdIfbYRMjtYC7fyzzm13SNqwBJWx6MRl3X jI3w==
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=tnqi9Z9gofsBQXA82sqVpawhYp8WofiFpp2PlYl/4bY=; b=O6XeHOuwolPG2BFOoi2ICrcA1SeHAs7qFc/OWIoKFBiPSxcPr+7v4pd0Z0Dw0v1vwU nGxVvrKDeKGFdSfnyknjQgPVPn5x1tEGv34v0ESuPJ5jHwhy3Ch/TnfjVcu8v0Pu0tna k0EfRj/b1qVheewGM7u99aibZXQk/W/gcNadRFO8iuTBL9S/tfDvAFy64ibZl4qpwWtW xozhaoj3L4ybtPY7+3+qr1MVJ/HjwsLNOC0eY/dl+KLR383D6lM06fMDAf/bkBvdgTcr SgGE/osvtXdfM/kEdUpZe1BPtJuTcUjQpx3vePkwD5Tb7PFQ1qJ2YEfQnK15ZIp3VFdf 4wHg==
X-Gm-Message-State: APjAAAWFAUjJTU0/hb0ZkAGPtt8qkA6M9ncC0NFO/8ULDt5Lu02Qr85G fjn1WOryQamn9dVx78sQ6RL0LAotK29TU+Fr2y4FuvM7uQ==
X-Google-Smtp-Source: APXvYqz6jbjyUb4OxowVKivCBiSglnhsF3ZdQl906QxZL/r/oX07pu0Vx9vWYvNhyr+sdfbB6Y4l+ciijZ9BignBuGk=
X-Received: by 2002:a81:844f:: with SMTP id u76mr24269434ywf.99.1579192841532; Thu, 16 Jan 2020 08:40:41 -0800 (PST)
MIME-Version: 1.0
References: <869491B5-9AA5-4593-A307-46FAAF7E990D@mit.edu> <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net>
In-Reply-To: <7B488048-896B-4F88-976C-909D0BFA16D3@lodderstedt.net>
From: Filip Skokan <panva.ip@gmail.com>
Date: Thu, 16 Jan 2020 17:40:30 +0100
Message-ID: <CALAqi__m2pAqsogmO17RM-63J9jmOn33UiEQjeFvHctAfhMLTg@mail.gmail.com>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>, Nat Sakimura <nat@sakimura.org>, "Richard Backman, Annabelle" <richanna=40amazon.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059f96b059c447c81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/e7iwdpbQuMyuCF_ALPfa8pK6fQQ>
Subject: Re: [OAUTH-WG] [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: Thu, 16 Jan 2020 16:40:48 -0000

Thinking of all the new edge cases we'd have to cover, i don't believe its
a good idea, as-is i see it elegant, capable of re-using existing
pipelines, the moment you change the parameter name new edge cases and
conditions start to popup. As an implementer i don't care that JAR says the
request_uri must reference a JWT, i know that requirement is in place for
the client<>AS contract. I'm fine with a language lifting that particular
requirement being present in PAR but i see that as a nitpick that adds
little to no real value to the final specification.

S pozdravem,
*Filip Skokan*


On Thu, 16 Jan 2020 at 17: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
>