Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 23 September 2019 19:40 UTC

Return-Path: <torsten@lodderstedt.net>
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 8C49E1200DB for <oauth@ietfa.amsl.com>; Mon, 23 Sep 2019 12:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level:
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 MKRLib21WK-U for <oauth@ietfa.amsl.com>; Mon, 23 Sep 2019 12:40:37 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (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 7CDAF120020 for <oauth@ietf.org>; Mon, 23 Sep 2019 12:40:37 -0700 (PDT)
Received: from [91.13.158.20] (helo=[192.168.71.102]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) (envelope-from <torsten@lodderstedt.net>) id 1iCUCH-0002M1-Ji; Mon, 23 Sep 2019 21:40:33 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-4916AC0A-98DB-46C3-9DD3-66F46B61435F; protocol="application/pkcs7-signature"; micalg=sha-256
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Mon, 23 Sep 2019 21:40:32 +0200
Message-Id: <FBF8A216-52D9-4858-A324-94F51A27CB31@lodderstedt.net>
References: <CAM7dPt2_52i1QA_MNi0GwASxvuO+K7pj6XD1x-i5=fEpgEn=7w@mail.gmail.com>
Cc: oauth <oauth@ietf.org>, Filip Skokan <panva.ip@gmail.com>
In-Reply-To: <CAM7dPt2_52i1QA_MNi0GwASxvuO+K7pj6XD1x-i5=fEpgEn=7w@mail.gmail.com>
To: Janak Amarasena <janakama360@gmail.com>
X-Mailer: iPhone Mail (17A577)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/23IlZ5D7u38C9wvkzQDSqFI5Mug>
Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt
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: Mon, 23 Sep 2019 19:40:43 -0000


> Am 23.09.2019 um 20:46 schrieb Janak Amarasena <janakama360@gmail.com>om>:
> 
> 
> Hi,
> 
>> Why do you think so?  
> 
> This is because I feel that validating the authorization request is part of the authorization process and doing the validation is the responsibility of the authorization endpoint.
>  
> 
>> I would assume the same core service is used to check the payload, so no code duplication required.
> 
> At the time what I meant was that the authorization request validation will be done twice. Once at the /as/par endpoint and again at the authorization endpoint. 
> 
> 
>> It also means the authorisation endpoint of the AS can safely assume all request URIs sent in Authorization Request that are minted by the same AS (which is detected based on its structure), are pre-checked and can be trusted (regarding the input validation).   
> 
> I see, so if the authorization request is validated at the /as/par endpoint the validation can be omitted at the authorization endpoint if the request contains a "request_uri" (given that it belongs to the AS). If this is the case I think it might be good to mention this in the spec with something like "The authorization server MAY decided to omit the validation of the authorization request if the uri sent in the request_uri parameter belongs to the authorization server." WDYT?

WFM

>  
> 
> Best Regards,
> Janak Amarasena
> 
>> On Mon, Sep 23, 2019 at 11:47 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> Hi Janak,
>> 
>> thanks for your feedback to PAR as well. 
>> 
>> > On 22. Sep 2019, at 21:51, Janak Amarasena <janakama360@gmail.com> wrote:
>> > 
>> > Hi,
>> > 
>> > Since the /as/par endpoint is intended to be used to store the actual authorization request I feel that validating the authorization request as mentioned in point 2 section 2.1(Request) should not be a responsibility of the /as/par endpoint and that it should not validate the authorization request.
>> 
>> Why do you think so?
>> 
>> Validating the request data at the pushed authorisation request endpoint has the advantage that the AS can refuse the process early. It also means the authorisation endpoint of the AS can safely assume all request URIs sent in Authorization Request that are minted by the same AS (which is detected based on its structure), are pre-checked and can be trusted (regarding the input validation).  
>> 
>> > Also, the majority case could be the endpoint receiving valid requests and the validation process will be duplicated at the authorization endpoint.
>> 
>> I would assume the same core service is used to check the payload, so no code duplication required.
>> 
>> > 
>> > Also since section 2.2 (Successful Response) states;
>> > The "request URI" MUST be bound to the "client_id" of the client that posted the authorization request.
>> > Wouldn't it be good to enforce the use of the clientId in section 4 (Authorization Request) when the authorization request is made with the "request_uri" parameter?
>> > GET /authorize?request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2&client_id=s6BhdRkqt3 HTTP/1.1
>> 
>> There is no need for an additional client id since the request URI is already bound to the client_id passed to and, in case of a confidential client, authenticated in the pushed authorization request.
>> 
>> best regards,
>> Torsten.
>> 
>> > 
>> > 
>> > Best Regards,
>> > Janak Amarasena
>> > 
>> > On Sat, Sep 21, 2019 at 4:32 PM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> > Hi all, 
>> > 
>> > I just published a new draft that Brian Campbell, Dave Tonge, Filip Skokan, Nat Sakimura and I wrote. 
>> > 
>> > https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
>> > 
>> > It proposes a new endpoint, called "pushed authorization request endpoint”, that allows the client to push the Authorization Request payload with the AS on a backchannel connection instead of a front channel interaction. The AS provides the client with a request URI (according to draft-ietf-oauth-jwsreq) that the client uses in a subsequent authorization requests to refer to the pushed request data. 
>> > 
>> > We believe this simple mechanism will significantly increase OAuth security and robustness since any application can use it by just sending the parameters in the same encoding as used at the authorisation endpoint over a HTTPS-protected and (for confidential clients) mutually authenticated connection to the AS. It can also be used to push signed and encrypted request objects to the AS, i.e. it provides an interoperable way to use request objects managed at the AS for use cases requiring an even higher security level.
>> > 
>> > We look forward to getting your feedback. 
>> > 
>> > kind regards,
>> > Torsten. 
>> > 
>> >> Begin forwarded message:
>> >> 
>> >> From: internet-drafts@ietf.org
>> >> Subject: New Version Notification for draft-lodderstedt-oauth-par-00.txt
>> >> Date: 21. September 2019 at 12:47:28 CEST
>> >> To: "Nat Sakimura" <nat@sakimura.org>rg>, "Brian Campbell" <bcampbell@pingidentity.com>om>, "Torsten Lodderstedt" <torsten@lodderstedt.net>et>, "Dave Tonge" <dave@tonge.org>rg>, "Filip Skokan" <panva.ip@gmail.com>
>> >> 
>> >> 
>> >> A new version of I-D, draft-lodderstedt-oauth-par-00.txt
>> >> has been successfully submitted by Torsten Lodderstedt and posted to the
>> >> IETF repository.
>> >> 
>> >> Name:                draft-lodderstedt-oauth-par
>> >> Revision:    00
>> >> Title:               OAuth 2.0 Pushed Authorization Requests
>> >> Document date:       2019-09-21
>> >> Group:               Individual Submission
>> >> Pages:               12
>> >> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-par-00.txt
>> >> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-par/
>> >> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
>> >> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-par
>> >> 
>> >> 
>> >> Abstract:
>> >>   This document defines the pushed authorization request endpoint,
>> >>   which allows clients to push the payload of an OAuth 2.0
>> >>   authorization request to the authorization server via a direct
>> >>   request and provides them with a request URI that is used as
>> >>   reference to the data in a subsequent authorization request.
>> >> 
>> >> 
>> >> 
>> >> 
>> >> Please note that it may take a couple of minutes from the time of submission
>> >> until the htmlized version and diff are available at tools.ietf.org.
>> >> 
>> >> The IETF Secretariat
>> >> 
>> > 
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>