[OAUTH-WG] PAR and client metadata

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

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 630E03A0E58 for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 13:09:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XozAUIJtJTvp for <oauth@ietfa.amsl.com>; Tue, 14 Apr 2020 13:09:23 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 67F163A0E57 for <oauth@ietf.org>; Tue, 14 Apr 2020 13:09:23 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id f8so760824lfe.12 for <oauth@ietf.org>; Tue, 14 Apr 2020 13:09:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=UINN27jivH9itUltYAuBCuuevMjliSAF9ng4o5mUw3Y=; b=U6Hoa5llF3NX0bET8elGPoHRmD0eBr6Sauc/Y9NZXcK585o55k9ygpH8KPDA2xfaEl tX9dg0bmas/HUwKSW1cA0mtC5n0txk24tYH/A3gAsCFrg3HF8MqEWRsCqP7NkhI6oryR HacHBd0RpnYSKpSPLbOoUr+jFP0LnBjuJ31HQGhg9YiJQfq4a0EFw8dn3rTZAIgXuiTq CoRMhKYoLeOfI1Uv+8cB7zZfmuBHc8nP6W+RHc60cemHo1CE6F0zjq7O4fwhCqxqPbm7 s1Zan0jY9qkoZ3cNQy3zcOeXC94abVokm9vkC59oULgSCWedUEQvfeznFaD3Usfoi5wX CUHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UINN27jivH9itUltYAuBCuuevMjliSAF9ng4o5mUw3Y=; b=bwd4qdXIovqusigI4l2AktfFePumwtb5edaKiwTptbgBEfiXAmcyRrYRzVDfNhxyA+ nvMDfaF8I8XibBTfHLft6xO02jxmRfOZyCo1cJBYrjggrvax1m+F0QGNo71+c5HKNpYo nWx+a7/GF1ahK62KeG2QHXFLTEutVQu89JgnGk6x6zVGMKVOwKymxBuWHcQDoqKzpMpl dMNEzRuqb1jsTfz9gXFOUg/9vag0Af1hozYoq+fR2JAEwg5vqWFhIYo1L1E0xYVo4ARt 2naP7B6qflG3CUPtsZB+iqNz199uUn7U4fSxgUadhwQ6Oq9BV2Xa1JRXlzQVdhZX5ucp pJAQ==
X-Gm-Message-State: AGi0PuaB7TOXzvac2fYRVQAkMc7kiFzjgy4IpVG/MLNDcXj1QSZWyG/g QwSqQEvsQmKrfAMk30Zn59v4BZz3D7qZeOykLC9NCfK4FSRCAuauZw+LXxJ6goPsftC+uH53rc4 Nte+3FPfsLEcxa+g2
X-Google-Smtp-Source: APiQypKAT/PaASEwrk95WTMUiPom9mhm/+KzvoGeokJo+v9Z1VyEIqO9bkC9NqLR9ju7SR8orKvkCRHLp5xEOYJ/ZTk=
X-Received: by 2002:a19:40ca:: with SMTP id n193mr859178lfa.196.1586894960760; Tue, 14 Apr 2020 13:09:20 -0700 (PDT)
MIME-Version: 1.0
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 14 Apr 2020 14:08:54 -0600
Message-ID: <CA+k3eCTHtpBD-=hZPuCwjcjc_55f-J6=RKe_OGuRW38Wnhm2Cg@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006ed44805a345c60e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OKUB5dkCwC1tDVknO0rVZYjbf-M>
Subject: [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:09:25 -0000

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
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._