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

Janak Amarasena <janakama360@gmail.com> Mon, 23 September 2019 18:46 UTC

Return-Path: <janakama360@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 8E84F12085E for <oauth@ietfa.amsl.com>; Mon, 23 Sep 2019 11:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 UPIEggye0fO8 for <oauth@ietfa.amsl.com>; Mon, 23 Sep 2019 11:46:06 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 0019312082B for <oauth@ietf.org>; Mon, 23 Sep 2019 11:46:05 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id p7so11150580wmp.4 for <oauth@ietf.org>; Mon, 23 Sep 2019 11:46:05 -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=3i6YRLdXdNxnwg/zaM2tfVIAR5OIWwgubAqzpM34w0w=; b=dcN7HjhDP7Qazm68z3m/0HOUwTSUIjn7CGuq0HGYWdZoQDbUECETJa0nzte1Z++Vsu C4+538xqvCYScKAIETps7OTqHH9zj5k+U148mZoIgGq2ECLXDTLtFyyxXxvM7LxlnRjK nXEcVTDjS1xL6zrdk5VeMDAs8WtGFEf5tClSbsIXBsHEDCEREdc781v8umfyMFOmTxsq h9MXBKoNnk928zgUiQ1l2Y+cgtmQ4q4tgNTw3VxUUlkLqqWTJ5a+eNg6D6doOgRHS1jT 9qotEOkk9heqQNJq+gwz2Tm3W7MCQsW8UmC+bd/UJYpgs9krgFdP2KD5ND7V945RgGe6 PiKQ==
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=3i6YRLdXdNxnwg/zaM2tfVIAR5OIWwgubAqzpM34w0w=; b=F4rbj5EZ9qBKechWp1tGRVYcfc0m22kT/fbCNizq/eQtpxRw8UfVUE6DPtsh48byVT ylE86zvOlBr/JOHBD5mU5uV7QpmAf/hlFn7tyPofwCjBAU7hY2/ZZKGc5e6B9PjcE8FX BGMH0F4b0FvGCzR5DSe340mBnqBfBfVgtG0cMB0qDH/N5SDMiK9MCpjp1O1pDqON+2JM kxXMfDAnx5U2qjGIx5vAq0940oiqL22bzGQKXxrNDt0pqogYrxnB//La/U5MapGaUdEq RTSvCJzjjdIbbVsx7Hw9QwQ3fnEjMBGRaRBTSo1EVzKRQHUA7ntAMUbu/m8fk7Q6NWNV NXow==
X-Gm-Message-State: APjAAAX9NvioeRouGnFu0KI8PX7obYvb0KPRWAkvx/LM541EQq2kM5Df 8RUNDeI5PXene57X8TXttbEhg4Z3RgMFBXO15EyrNQ==
X-Google-Smtp-Source: APXvYqyIgtlkP66m7yKODIZxAS+wythWt+k057fHV7/YSk4oyOly9gW+PYQUnD0KTOVfh5wLOGqtQY9hfeAnwam2GZI=
X-Received: by 2002:a05:600c:2252:: with SMTP id a18mr790533wmm.141.1569264364293; Mon, 23 Sep 2019 11:46:04 -0700 (PDT)
MIME-Version: 1.0
References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <CAM7dPt0Urr1H=ThKsG27Xt+woCqwj0Ue2b5Of1CcSd3=9pO_4g@mail.gmail.com> <DF0F96CC-109E-40F9-A2B2-9DC6F108B0BA@lodderstedt.net>
In-Reply-To: <DF0F96CC-109E-40F9-A2B2-9DC6F108B0BA@lodderstedt.net>
From: Janak Amarasena <janakama360@gmail.com>
Date: Tue, 24 Sep 2019 00:15:31 +0530
Message-ID: <CAM7dPt2_52i1QA_MNi0GwASxvuO+K7pj6XD1x-i5=fEpgEn=7w@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>, Filip Skokan <panva.ip@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000fe2a7905933cd48f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Bm05HNERTs1KYLw9xfQT-qArg18>
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 18:46:09 -0000

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?


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>, "Brian Campbell" <
> bcampbell@pingidentity.com>, "Torsten Lodderstedt" <
> torsten@lodderstedt.net>, "Dave Tonge" <dave@tonge.org>, "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
>
>