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

Brian Campbell <bcampbell@pingidentity.com> Mon, 30 September 2019 15:46 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 BA526120813 for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 08:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 OPpHduWSBfNb for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 08:46:09 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 368471200CD for <oauth@ietf.org>; Mon, 30 Sep 2019 08:46:09 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id a1so39568427ioc.6 for <oauth@ietf.org>; Mon, 30 Sep 2019 08:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/yBOLR7uWzSeU6AUiuJ6dHysGNUWvySDCJZkAVlEOTA=; b=mJ6Ek+hyB5oHLadAwyJyo9eTs1aMPszhMqAX2Fz9IVmeXP9Lj7V5CUwxhTNXnjYy13 A6eG1rx0fTLmZ5KvZsjYZKB3fHuckTNqcctmKrZ5w/HpE2GPhuCmfPVmLT8c5bEsysD2 NWQRYF+Lhl2DbjCZkuh01yZhVYZ/0gdAKvFJs=
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=/yBOLR7uWzSeU6AUiuJ6dHysGNUWvySDCJZkAVlEOTA=; b=VaFfNCkskNP9UFp6taAKWznLvVcwEAY2nNrlpTJr1+dARftdOivIQW9T1wzDO2iupY 6B1VXRO1Wq68xHwB9e7bDTKq3IsVQcAukchwaeZGg28r8qnl95yQzrZlpuqYXkKUbntQ yHiWThLprM/rWSWsuNylnMsu4r+nhcxOTYacqJ6+HoOWC4ChZS27sYtl1cLcKobMISDQ YyIQSIJmbSNS2wUpWl3Ut2ug3nMPUZ3D0nP1D36Fc+oZPxmg2pL5DqEzYQr0vHMcX0jb EVxpZ8cgjptWB3C7EAs0XAGvz4jL0rX7zDuBYpt3R+9thMGCAp8Y0UJpKhOJ1Hd345Zq GNiw==
X-Gm-Message-State: APjAAAUCIDkrtqA3ESeHRsDvI5JkqwPMB4CiyijCr02LvubJPKFWEpol wbni9ckWLdJoKUo+PY0lkaTjig7BR+8w9cdz/OmTHya7keODzUws8mu1Z3qw7W+H7aoEoAvgz4z fzF2W6/jMcTsDEg==
X-Google-Smtp-Source: APXvYqz2PXSwGhOFA4Wxseju/AlQKTgx8SERwZfs4//+ufDiTPiu5ToE4s/rjsqljRw515fDCX4mPfJpRbfEJ9nHsjM=
X-Received: by 2002:a92:d1c5:: with SMTP id u5mr21103663ilg.201.1569858368355; Mon, 30 Sep 2019 08:46:08 -0700 (PDT)
MIME-Version: 1.0
References: <156906284888.22977.8893219801768603786.idtracker@ietfa.amsl.com> <1842D9CD-1B5B-420A-AA43-7B30F3CE13B8@lodderstedt.net> <CAGBSGjqdrCOZAu_2VvtjHVD+rBEK+0B86wNjoyXiQKAwS2Q4hA@mail.gmail.com> <BB0AE29D-5CD0-4441-B3B6-FEB6D3F749EE@mit.edu>
In-Reply-To: <BB0AE29D-5CD0-4441-B3B6-FEB6D3F749EE@mit.edu>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 30 Sep 2019 09:45:40 -0600
Message-ID: <CA+k3eCRJho42cYGG1OfHvRg1CdTH3W8peFHnZtFrsB5Fsvru2A@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Cc: Aaron Parecki <aaron@parecki.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000064e66c0593c722cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HcV3kIi4P2-9SQ4IQfSIflc1Jek>
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, 30 Sep 2019 15:46:12 -0000

On Thu, Sep 26, 2019 at 10:50 AM Justin Richer <jricher@mit.edu>; wrote:

>  If, for whatever reason, it is required that this value is
> actually a URI, is there some expected namespace to use other than
> "example"? I worry that if all the examples in the spec are just
> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
> using the text "example" because they don't understand why it's there,
> and then it serves no purpose really.’
>
>
> This field must be a URI, as per JAR:
>
>    request_uri  The absolute URI as defined by RFC3986 <https://tools.ietf.org/html/rfc3986> [RFC3986 <https://tools.ietf.org/html/rfc3986>] that
>       points to the Request Object (Section 2.1 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.1>) that holds
>       authorization request parameters stated in section 4 <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-4> of OAuth 2.0
>       [RFC6749 <https://tools.ietf.org/html/rfc6749>].
>
> Somewhat awkwardly, the JAR spec currently states that the AS has to do an
> HTTP GET on the request URI, so that will need to be fixed in JAR before it
> goes forward. I don’t think that was always the case though, and I’m not
> sure how that changed.
>

JAR does have a somewhat awkward allowance for not doing a GET in
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-5.2.3 saying
an AS "MUST send an HTTP "GET" request to the request_uri to retrieve the
referenced Request Object, unless it is stored in a way so that it can
retrieve it through other mechanism securely."

So I'm guessing maybe nothing actually changed but it's just hard to find
in the document.



> As for the namespace, “example” is ok for an example URN. The problem with
> URNs is that nobody really understands how to do domain-safe fully
> compliant URNs. So perhaps we should instead use “urn:fdc:example.com:….”
> Instead (as per https://tools.ietf.org/html/rfc4198).
>

Something else to consider additionally or alternately is that the document
could provide some suggestions/guidance or even requirements on the
structure of the URN for this self referential case. It could, for example,
use the RFC6755 subnamespace and registry and be of the form
urn:ietf:params:oauth:request_uri:<handle> or
urn:ietf:params:oauth:request_uri;<handle> or
urn:ietf:params:oauth:request_uri?value=<handle> or
urn:ietf:params:oauth:request_uri#<handle> or however the proper way to do
that would be.

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