[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 17:57 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 CF1E912018A for <oauth@ietfa.amsl.com>; Thu, 25 Jul 2019 10:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DCm93-iIRArs for <oauth@ietfa.amsl.com>; Thu, 25 Jul 2019 10:57:22 -0700 (PDT)
Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (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 D1AB1120183 for <OAuth@ietf.org>; Thu, 25 Jul 2019 10:57:18 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=aLf5vUDEj8vowT2Ma57+CBlcBQRmV+mgjI5pz9LcK0U=; b=W/wCL26RKO8fmpbv3/mn3EeSHQCdURJwdbA2Ng4KT2i/9oozHU0I5HKPhIWJtf0CLDS/ZNLPcZquLvMZT9whr9KZVey8tnu7sGxneYe710kc+vnKr1vYH19LeDxQ4jDDNWsBkjWkP9TyfGRzOJBi+uBoO7MGAcXZWODUqE+2yl0=;
Received: by smtp49.i.mail.ru with esmtpa (envelope-from <tangui.lepense@mail.ru>) id 1hqhzQ-0001Lx-8U for OAuth@ietf.org; Thu, 25 Jul 2019 20:57:16 +0300
To: OAuth@ietf.org
From: Танги Ле Пенс <tangui.lepense@mail.ru>
Message-ID: <10d9fb21-f448-aba5-5d11-308e34a34fdd@mail.ru>
Date: Thu, 25 Jul 2019 20:57:15 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Authentication-Results: smtp49.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 689590B63E0A4B015A78504BD2AC294173B0C787F0EA2BA1BF5CD33FC2D754D2659108408DFACAD3E0987D2BEF3AB90E
X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7B198AA70935470D0EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637695C86F4341D7D1D8638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FC58B8FFCA48A21AB86BB211BC80723F012BEA67288B58D17A389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0A3E989B1926288338941B15DA834481FCF19DD082D7633A0E7DDDDC251EA7DABA471835C12D1D977725E5C173C3A84C3E478A468B35FE767117882F4460429728AD0CFFFB425014E40A5AABA2AD371193AA81AA40904B5D9A18204E546F3947C3E2C50380ACA2941BA3038C0950A5D36C8A9BA7A39EFB766F5D81C698A659EA73AA81AA40904B5D98AA50765F7900637E7B8A58B8C55070EEC76A7562686271EBE1D6DAAD8F14AE1089D37D7C0E48F6C8AA50765F790063702CA68E78BD0E2C3C53DF2FDDED51211089D37D7C0E48F6C5571747095F342E857739F23D657EF2B6825BDBE14D8E7024847893F9AA87235E5BFE6E7EFDEDCD789D4C264860C145E
X-Mailru-Sender: 14EA92FCC1671FFE4D769571F75AF8D420BE4B2E1075E45822DAF15015123C9598A2A4A1A9C1144CCA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jOYNIPk8qxnt-iXMaOTw74sFLQA>
Subject: [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 17:57:25 -0000
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) 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. Another option is not redirecting and displaying the error message on the AS, like when the client_id is unknown for instance. Also I don't get the example in 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%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? Maybe I've missed something? Regards, -- Tangui
- [OAUTH-WG] Where to redirect when object request … Танги Ле Пенс
- Re: [OAUTH-WG] Where to redirect when object requ… Filip Skokan
- Re: [OAUTH-WG] Where to redirect when object requ… Танги Ле Пенс
- Re: [OAUTH-WG] Where to redirect when object requ… Filip Skokan