Re: [OAUTH-WG] PAR and client metadata

Brian Campbell <bcampbell@pingidentity.com> Tue, 14 April 2020 21:43 UTC

Return-Path: <bcampbell@pingidentity.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 60E183A1095 for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 14:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=pingidentity.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 vSOtyBN0v9bQ for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 14:43:53 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 158E23A1092 for <oauth@ietf.org>; Tue, 14 Apr 2020 14:43:52 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id r7so1410580ljg.13 for <oauth@ietf.org>; Tue, 14 Apr 2020 14:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1l5GC9vl/iBtAY2Sb9J6AruEzv+pfd9vhv/PfJtS8QU=; b=P/RUyBZ90UZRaWLlP6wuc8JDajFUc4uG4TTNSpzGH2fAPUsRTqw78liSD1KRKJmzSs VDN+DqAE+uLFZ2VjpYAzFUIVExX0mIpuD7500V2V4JW7o5avSI3g8MeijLRep22azRBI X3+/8ZbCEcA9sbNMcy3nRY70zfCV8+K+g6bEiXyGjfyYwXOrdfgc2BQWND00FMCMw3Nr 8tbXj5ZjZ3z6Qd+rnX/LO1Ls8Gmmqr/CIoYPl2QPCl+Yi5W4NddqmFyjd5jWRtov3Lf9 hdGmzsoHT1hHNtIKG3/LOlkAZTnu3HMaZvGjoLtcdzIvpDuAKc9QH72aOe8qshj/Q0SD A4+Q==
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=1l5GC9vl/iBtAY2Sb9J6AruEzv+pfd9vhv/PfJtS8QU=; b=DBnWptmJM7He3b9ukh35wr9EefQQ0IlWaF1QD151RnRmNri708uPduTMDug1nw8Vq8 u+g0TcdlJ1x9BaTp2tfQer6/8xmPKlod41P9u/gt3UYB32cLTlMhUV88sOjvrrGwcHxY g7y29rI8FJAtZGFhcPzMP3PtuT1r0Zweg3D5uzNb99u3KBQTL4oMsdAHdMHpQPHn8TQl YBnSWZ7Ao0iS0KfWaDyPP6S1edwNbfPG61HLfBu7c6dcxkPruqUk4BU5rkzKNZpnv0R3 mpjHyayzDRu84EkEth2vnZIB2AsTr421D8CSlj9gRH3uCMCpG//miOUN+XDke9eBZ+xm h7Pw==
X-Gm-Message-State: AGi0Pubfpp95wfaiW0dfhqRlqQiWNl77toMUzQALDI2fu2onSSK4C0F/ 2APE5TUbdnxUwuXRmDIQhm89mBc/HuzUvszJk7BhsNhd3zMwz//LJPr9t+5WeMoaR3qFxvSMQeP 17fpv0Zd6XBkEmTUSmB0=
X-Google-Smtp-Source: APiQypJzcEgfChrwYQPpOTCitmIdahHokUdlg0maMCJoTbvfVU1VINy+ZxTwU9JM+d4TWuEz+1zf4IXKAMHLG58zTXA=
X-Received: by 2002:a2e:2a85:: with SMTP id q127mr1243064ljq.273.1586900631133; Tue, 14 Apr 2020 14:43:51 -0700 (PDT)
MIME-Version: 1.0
References: <CA+k3eCTHtpBD-=hZPuCwjcjc_55f-J6=RKe_OGuRW38Wnhm2Cg@mail.gmail.com> <b9259eaa-23e5-1893-9817-f5757cb826d1@connect2id.com>
In-Reply-To: <b9259eaa-23e5-1893-9817-f5757cb826d1@connect2id.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 14 Apr 2020 15:43:24 -0600
Message-ID: <CA+k3eCQpxEWL522XaXXZ5tLtMo0-sb1pKk2XeOq_VnVnjxEuTw@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000069b91805a3471816"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PMV3wvSoxDTom-PUM6MB3Ld6zGg>
Subject: Re: [OAUTH-WG] PAR and client metadata
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: Tue, 14 Apr 2020 21:43:55 -0000

I was hoping to get to a rough consensus in support of the idea before
coming up with a name that everyone will hate :)

In the meantime, however, name suggestions are of course welcome.


On Tue, Apr 14, 2020 at 2:22 PM Vladimir Dzhuvinov <vladimir@connect2id.com>
wrote:

> I'm all for that.
>
> I suppose you have already thought of a suitable name? :)
>
> Vladimir
> On 14/04/2020 23:08, Brian Campbell wrote:
>
> Using PAR can facilitate improved security by giving clients a
> (relatively) simple means for sending a confidential, integrity protected,
> and (for confidential clients anyway) authenticated authorization request.
>
> It seems like some of that improved security could be undermined by a
> malicious actor somehow getting a user to navigate to a URL of a regular
> old parameterized authorization request. One variation of the Mix-Up Attack
> does this
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-4.4.1
> for example and email, social media, online forums, etc., are other ways a
> user might be tricked into following a maliciously crafted link.
>
> Following from that it seems logical that an authorization server might
> want to restrict some clients from sending a regular parameterized
> authorization request and instead require use of the PAR endpoint to
> initiate an authorization request. Something like this could, of course, be
> implemented as custom policy or configuration in any AS. But I'm thinking
> it might be common enough to warrant adding a client metadata parameter to
> the PAR draft specifically for it. The metadata (and registered extensions)
> defined by Dynamic Client Registration [RFC7591] has come to imply a
> general data model and expected associated behaviors for clients that is
> useful for authorization server implementations, even when the Dynamic
> Client Registration Protocol isn't directly in play. This particular
> situation seems like a good potential candidate for a new such client
> metadata parameter that would indicate that the given client can only use a
> request_uri value obtained from the PAR endpoint to initiate an
> authorization request. And that a regular old fashioned authorization
> request from the given client would result in an error.
>
> Do the folks of this fine WG think something like this would be a
> worthwhile addition to the PAR draft?
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited..
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._