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

Танги Ле Пенс <tangui.lepense@mail.ru> Thu, 25 July 2019 18:48 UTC

Return-Path: <tangui.lepense@mail.ru>
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 D60FD1201B0 for <oauth@ietfa.amsl.com>; Thu, 25 Jul 2019 11:48:13 -0700 (PDT)
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, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru
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 jpc5VCY-lo0R for <oauth@ietfa.amsl.com>; Thu, 25 Jul 2019 11:48:09 -0700 (PDT)
Received: from smtp54.i.mail.ru (smtp54.i.mail.ru [217.69.128.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D5F1201A0 for <OAuth@ietf.org>; Thu, 25 Jul 2019 11:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=wmm052+VTO8jdcjhIxVduLcCoBm5eph6vpXNssvVjm8=; b=ftsCcy57cuAlLQkjl4EMA/odoAvN4YDZ44Rwj9YWban90/UdN5BEW3H8Db50lJEwtuxgTQncg0hQSYJYq9rWP1VRdif6rOhFjNssBbhXxlCLTyITb8cBQMs3Rw5yMakadnZ+nKf5h5QlAwHSKrwcnrd9uybHJcXpSgYfDIWqB9A=;
Received: by smtp54.i.mail.ru with esmtpa (envelope-from <tangui.lepense@mail.ru>) id 1hqimc-0006pt-Nu; Thu, 25 Jul 2019 21:48:07 +0300
To: Filip Skokan <panva.ip@gmail.com>, =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= <tangui.lepense=40mail.ru@dmarc.ietf.org>
Cc: oauth <OAuth@ietf.org>
References: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru> <CALAqi__Xrsu2OwhYPZJ-5_7woF-UcEjoUszd49z745p9dRo5YQ@mail.gmail.com>
From: =?UTF-8?B?0KLQsNC90LPQuCDQm9C1INCf0LXQvdGB?= <tangui.lepense@mail.ru>
Message-ID: <3a0cd3ab-b236-05da-a1b9-ab7d57646b48@mail.ru>
Date: Thu, 25 Jul 2019 21:48:04 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CALAqi__Xrsu2OwhYPZJ-5_7woF-UcEjoUszd49z745p9dRo5YQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Authentication-Results: smtp54.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 3FFC80838138E3AB5A78504BD2AC294173B0C787F0EA2BA1667A1FD3CE774639CB2022ED40CBBBD3DA91B6C4C7D8E2FC
X-7FA49CB5: 0D63561A33F958A50AD8B216AB446C668AD1DD314D16F985F1222E096041C3ED8941B15DA834481FA18204E546F3947CB861051D4BA689FCF6B57BC7E64490618DEB871D839B7333395957E7521B51C2545D4CF71C94A83E9FA2833FD35BB23D27C277FBC8AE2E8B3A703B70628EAD7BA471835C12D1D977C4224003CC8364767815B9869FA544D8D32BA5DBAC0009BE9E8FC8737B5C224988F0F0F8BA165F5C76E601842F6C81A12EF20D2F80756B5F868A13BD56FB6657D81D268191BDAD3D78DA827A17800CE7436E4CC186B5AB2DB3661434B16C20AC93541453170D46FCAAAE862A0553A39223F8577A6DFFEA7C045B4009A2530507752512DE092FF5CCEFF80C71ABB335746BA297DBC24807EA27F269C8F02392CDC58410348177836EABEDDA51113D120200306258E7E6ABB4E4A6367B16DE6309
X-Mailru-Sender: 14EA92FCC1671FFE4D769571F75AF8D4A952EE5F2A92D8AD243C758D39EB3F0454E284FD4F22E913CA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/48SQPd9Ejm1pXhVSk_WCj879etQ>
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: Thu, 25 Jul 2019 18:48:14 -0000

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