Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)

Filip Skokan <panva.ip@gmail.com> Fri, 26 July 2019 10:59 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 6A5E21202E8 for <oauth@ietfa.amsl.com>; Fri, 26 Jul 2019 03:59:07 -0700 (PDT)
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 5yXmfRN4stoV for <oauth@ietfa.amsl.com>; Fri, 26 Jul 2019 03:59:04 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 ABE1112024F for <OAuth@ietf.org>; Fri, 26 Jul 2019 03:59:04 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id j11so30648230otp.10 for <OAuth@ietf.org>; Fri, 26 Jul 2019 03:59:04 -0700 (PDT)
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=7I23CNQxCkYLgDr2oLUYi+BIikNGGvkS5jsbnQyienA=; b=d1Byq3W0woJ7pHh7lVqK9L38CyQRwBKxUPsAgZBCRcah7emAtmZS5vISgV823rlepN VDixDvddviktglZK51GFpg88ZgZnbln9Z09iGA/ihV9svJmGfgWR7zSyHNih0Tvwwvos O+srl4bORE2Y99tru5W1gYWPb7a9xhcGpgcxiH3gpTh7DRSxNf0qNgtnNkVqO7dHIvgA ukiEO3x+wmPUjyDFgmyC5mOJm+YJvQmNsxVyF4I71uvAmg8teualsogJ9UISxH7sqYTv wSCeh41A7K3XA3LnVW2aWxlsA+Xg13XML8Ydb7kQ9NzdbY4Rb38XnczIFcFvwrTZ1IPd G4iQ==
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=7I23CNQxCkYLgDr2oLUYi+BIikNGGvkS5jsbnQyienA=; b=ckQV43a5CXhIX86yEgI1/qMiY6cwoE25v5aArIXCe5s+nhZa0r3yjrKCL20hm8KooM 8BzKYxEzYhOwbPF39kFI0/8cO8OOYLUdYBSyppzUpuKmplTDsTtkTYGNOuGBPiyWnkZF xVw5s9yt/T6zDqXcITlHcA6/jP6SemUIPG2hXW6ZuUciUG4UP9f0wcdiWOoJV6M6gESP TtslGzR737hv5ZagWkI7EUnoBECJaSq/FrSfS3G5W1M8eEthxFCMagTO+wcriQ3vFpAl dI3exsUd0wgVH6ZvSNK+Tqe8xVKOsArh5wMLa4LyC27mmkjdyJ8HbutA4G1h4MOKQyxI WG0Q==
X-Gm-Message-State: APjAAAVYuEALPHFfRIXG4OGF/pyFjkGRJziIxMFlNWLWVcUl55232Hhe EXkfNtt7Qo0Z9B7+ey5mcg6nuJpGAG8PlIt2xg==
X-Google-Smtp-Source: APXvYqybd2YsuJxB73VpcRY6SScmd6uIPsLQaja5Bypn3C/aL/Osn+saBTB2+Dq3MP3Y8upeJZZ9bR/+ZgGdVg5cydY=
X-Received: by 2002:a9d:2c26:: with SMTP id f35mr68056414otb.362.1564138743739; Fri, 26 Jul 2019 03:59:03 -0700 (PDT)
MIME-Version: 1.0
References: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru> <CALAqi__Xrsu2OwhYPZJ-5_7woF-UcEjoUszd49z745p9dRo5YQ@mail.gmail.com> <3a0cd3ab-b236-05da-a1b9-ab7d57646b48@mail.ru>
In-Reply-To: <3a0cd3ab-b236-05da-a1b9-ab7d57646b48@mail.ru>
From: Filip Skokan <panva.ip@gmail.com>
Date: Fri, 26 Jul 2019 12:58:52 +0200
Message-ID: <CALAqi__6SpcT5FwPKxMLRnwRTQB1CdpwiP-tDuvc5L3bWgWhAw@mail.gmail.com>
To: Nat Sakimura <sakimura@gmail.com>, John Bradley <jbradley@yubico.com>
Cc: oauth <OAuth@ietf.org>, =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= <tangui.lepense@mail.ru>
Content-Type: multipart/alternative; boundary="000000000000333924058e936ed8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5dXLrFCQ2WxBVxsIG7Zm0vL6DZE>
Subject: Re: [OAUTH-WG] Where to redirect when object request is invalid or unreachable (draft-ietf-oauth-jwsreq-19)
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, 26 Jul 2019 10:59:08 -0000

John, Nat,

Tangui raises a good point I have missed,

draft 14 of jwsreq (JAR) introduced this language

The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object. *


Server MUST only use the parameters in the Request Object even if the
> same parameter is provided in the query parameter.  The Authorization


The client MAY send the parameters included in the request object
> duplicated in the query parameters as well for the backward
> compatibility etc.
>
> *However, the authorization server supporting this specification MUST only
> use the parameters included in the request object. *


Nat, John, everyone - *does this mean a JAR compliant AS ignores everything
outside of the request object while OIDC Request Object one merges the two
with the ones in the request object being used over ones that are not?* The
OIDC language also includes sections which make sure that some required
arguments are still passed outside of the request with the same value to
make sure the request is "valid" OAuth 2.0 request, something which an
example in the JAR spec does not do. Not having this language means that
existing authorization request pipelines can't simply be extended with e.g.
a middleware, they need to branch their codepaths.

Thank you for clarifying this in advance. I think if either the behaviour
is the same as in OIDC or different this should be called out in the
language to avoid confusion, especially since this already exists in OIDC
and likely isn't going to be read in isolation since its even called out to
be already in place in OIDC.

S pozdravem,
*Filip Skokan*


On Thu, 25 Jul 2019 at 20:48, Танги Ле Пенс <tangui.lepense@mail.ru>; wrote:

> Filip, thank you for your reply. Additional remarks inline.
>
> On 25.07.2019 21:14, Filip Skokan wrote:
> > See my reply inline.
> >
> > S pozdravem,
> > *Filip Skokan*
> >
> >
> > On Thu, 25 Jul 2019 at 19:57, Танги Ле Пенс
> > <tangui.lepense=40mail.ru@dmarc.ietf.org
> > <mailto:40mail.ru@dmarc.ietf..org>> wrote:
> >
> >     In
> >     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-6, it
> >     is stated that an error is to be returned when the object request is
> >     invalid. These errors are "invalid_request_uri" and
> >     "invalid_request_object".
> >
> >     However, to which redirect URI redirect in the following cases:
> >     * the request object is invalid (eg. invalid signature), should we
> >     still
> >     use client_id/redirect_uri of the invalid request object?
> >
> >     * the request URI could not be reached
> >     * the request object is encrypted and cannot be decrypted (bad key)
> >
> >
> > FS: if the client_id & redirect_uri combination is valid (the uri is
> > valid for that client) - yes, its fine to use those (dtto state). this
> > applies to all three
>
> It doesn't apply to an encrypted object that cannot be decrypted.
>
> >
> >     Would it be acceptable to use the "client_id" and "redirect_uri"
> >     request
> >     query parameters in such a case? Although it contradicts the current
> >     specification which states that they shall not be used, and it would
> >     defeat confidentiality when using encryption.
> >
> >
> > FS: how would it defeat confidentiality?
> If you use a JWE in the first place, it's so that the parameters cannot
> be read on the wire.
> >
> >
> >     Another option is not redirecting and displaying the error message on
> >     the AS, like when the client_id is unknown for instance.
> >
> >
> > FS: also an acceptable outcome, one with no caveats
>
> Except degraded UI for the end user, if we assume that an error on the
> client side is easier to manage that a cryptic error on the AS with no
> link back to the client. Also, the client could have a retry strategy
> (it might just be that the request object at the request object URI is
> expired, due to network latency, etc.).
>
> So if my understanding is correct, it's up to the implementer to make a
> decision on this point? Couldn't it lead to incompatibility, divergent
> implementations?
>
> >
> >     Also I don't get the example in
> >     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.2
> >     <
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5..2.2>
> >     :
> >
> >     https://server.example.com/authorize?
> >             response_type=code%20id_token
> >             &client_id=s6BhdRkqt3
> >             &request_uri=https%3A%2F%2Ftfp.example.org
> >     <http://2Ftfp.example.org>%2Frequest.jwt
> >             %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
> >             &state=af0ifjsldkj
> >
> >     in regards to the following statement in
> >     https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5 :
> >
> >         The client MAY send the parameters included in the request object
> >         duplicated in the query parameters as well for the backward
> >         compatibility etc.  However, the authorization server
> >     supporting this
> >         specification MUST only use the parameters included in the
> request
> >         object.
> >
> >     My understanding is that "response_type", "client_id" and "state"
> >     will
> >     be ignored by a JAR-compliant OAuth2 server. Isn't it confusing to
> >     add
> >     them to the example?
> >
> >
> > FS: they will only be ignored IF they are also part of the request
> > object so i believe its fine to have them part of this example.
>
> It's seems ambiguous to me when reading the specification.
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4 states
> that:
>
> A Request Object (Section 2.1  <
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) is
> used to provide authorization
>     request parameters for an OAuth 2.0 authorization request.  It MUST
>     contains all the OAuth 2.0 [RFC6749  <
> https://tools.ietf.org/html/rfc6749>] authorization request parameters
>     including extension parameters.
>
> So there'd be no such thing as "client_id" and "redirect_uri" as query
> parameters, and other parameters members of the request object in my
> interpretation.
>
> In OpenID Connect you can indeed have both, the request object's
> parameters having precedence over query parameters
> (https://openid.net/specs/openid-connect-core-1_0.html#RequestObject):
>
> When the request parameter is used, the OpenID Connect request parameter
> values contained in the JWT supersede those passed using the OAuth 2.0
> request syntax. However, parameters MAY also be passed using the OAuth
> 2.0 request syntax even when a Request Object is used; this would
> typically be done to enable a cached, pre-signed (and possibly
> pre-encrypted) Request Object value to be used containing the fixed
> request parameters, while parameters that can vary with each request,
> such as state and nonce, are passed as OAuth 2.0 parameters.
>
> What do you think?
>
> >
> >     Maybe I've missed something?
> >
> >     Regards,
> >
> >     --
> >     Tangui
> >
> >     _______________________________________________
> >     OAuth mailing list
> >     OAuth@ietf.org <mailto:OAuth@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>