Re: [OAUTH-WG] PAR and client metadata
Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 14 April 2020 20:22 UTC
Return-Path: <vladimir@connect2id.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 11FC63A0EAC for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 13:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 UDoS3LARrJZw for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 13:21:58 -0700 (PDT)
Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net [68.178.252.111]) (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 0C0FD3A0EAA for <oauth@ietf.org>; Tue, 14 Apr 2020 13:21:57 -0700 (PDT)
Received: from [192.168.88.241] ([94.155.17.54]) by :SMTPAUTH: with ESMTPSA id OS4Bj1f86C3bYOS4CjgpZs; Tue, 14 Apr 2020 13:21:57 -0700
X-CMAE-Analysis: v=2.3 cv=NZSYKFL4 c=1 sm=1 tr=0 a=FNQ4XmqxRr20pcroDK0mpg==:117 a=FNQ4XmqxRr20pcroDK0mpg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=q0rX5H01Qin5IyBaTmIA:9 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=hhYmk6OB3ath9ieCrv0A:9 a=QEXdDO2ut3YA:10 a=pGLkceISAAAA:8 a=8FXbpEt50JgLI2hA1oMA:9 a=v77YmzfvTsoNDJpf:21 a=_W_S_7VecoQA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <CA+k3eCTHtpBD-=hZPuCwjcjc_55f-J6=RKe_OGuRW38Wnhm2Cg@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <b9259eaa-23e5-1893-9817-f5757cb826d1@connect2id.com>
Date: Tue, 14 Apr 2020 23:21:55 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCTHtpBD-=hZPuCwjcjc_55f-J6=RKe_OGuRW38Wnhm2Cg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms050001070602020207040708"
X-CMAE-Envelope: MS4wfPPvObCwkK5fG3rC+YjfQNEGIKSvCUB4JVYB9ADC6F4zBU5nw9xcSROx3Vm/Nek8adbUF9yNhy+fkwLGq6f3ONdcTwuP2T5XMTGukj81+FIldXwiIWoo 93pNDjIZfD/xJZVR09+gUhOzerZB29cfxlNlYGWmWqCEqUq3f5SUBRdd
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Q6RJRWyh7ioWT4C35Ygz9e7u-Ps>
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 20:22:00 -0000
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 list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Vladimir Dzhuvinov
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Richard Backman, Annabelle
- Re: [OAUTH-WG] PAR and client metadata Filip Skokan
- Re: [OAUTH-WG] PAR and client metadata Sascha Preibisch
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata George Fletcher
- Re: [OAUTH-WG] PAR and client metadata Torsten Lodderstedt
- Re: [OAUTH-WG] PAR and client metadata George Fletcher
- Re: [OAUTH-WG] PAR and client metadata Vladimir Dzhuvinov
- Re: [OAUTH-WG] PAR and client metadata Torsten Lodderstedt
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Filip Skokan
- Re: [OAUTH-WG] PAR and client metadata Brian Campbell
- Re: [OAUTH-WG] PAR and client metadata Torsten Lodderstedt