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

Brian Campbell <bcampbell@pingidentity.com> Mon, 30 September 2019 16:15 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 79BA9120820 for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 09:15:10 -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 fZC9C6cZPvjo for <oauth@ietfa.amsl.com>; Mon, 30 Sep 2019 09:15:08 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 81EF5120837 for <oauth@ietf.org>; Mon, 30 Sep 2019 09:14:59 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id v2so39704949iob.10 for <oauth@ietf.org>; Mon, 30 Sep 2019 09:14:59 -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=uLN6g8rcykkbdOzD4a39oWB7aaZ26i/5GbI89AANUiw=; b=kYnPVtnvyv/DTDj1XRuzEkB0U3ggb738rIOEA9QsYywKY0kYmx8E7KKJd+1w3hYT0n +6+9Z1pNNgQI/7lXA3g03W9k298AnqPZIVn3OylE3c6Nv7F2MRYjtciZM2k4EygViEct e7w2nJA5GYgq88UWHoz///loRFS44q/W11MLU=
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=uLN6g8rcykkbdOzD4a39oWB7aaZ26i/5GbI89AANUiw=; b=pCDKLsT6SyBJnG/oxuDAyUCDbyP/+ydLiiOqZNlK98AYTH2zag+TGrj/ePRmBSBtoO abELE3knzhImMbSEv+ha70TEY4bYhCqXHUXYgzbZfllOEimDBVLAUrW8TvhgE2uXHdHW BOmaTUeuMopuS9UI3NEK+XPnRhHX0nh549WyeS3IYjHlVq8vdM6Rork5VtGcWw2/7LEv bHHSrZw8K+AJLjQri4wHDh58gQBozDEWnSotcvxLqEuPEmu9GqkHJNm0KvgPVz86BqPD AgucTJ3MbW3G8sKXE0CWsqwHfJ/5PCHSn2xBLtojQFUtn+rmrLNiQA79p1/H0GRGo8tJ VqVQ==
X-Gm-Message-State: APjAAAXq8cGh20YVdDWMhb9lDCY8F3kWsBDQFxZSAxM0KaHQFIcAEUg8 H53bRNM5hYyJ6KK35LFv5ocnWIC8QocUPq5t8r9L8nGcXrog2eTg2EVeKkH25ChAnAx85XIVmsu 6Q/94f3bsEDrb+JLa
X-Google-Smtp-Source: APXvYqzUfKo9n6J3r7jnJj0KE5TVKSu5FFKCTeivgZaBR0b0YUCQM/MNA6tvOGpVMyDgn4YNrnN4Ad7J9nmyEMl7Ykk=
X-Received: by 2002:a6b:b494:: with SMTP id d142mr19767367iof.156.1569860098783; Mon, 30 Sep 2019 09:14:58 -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> <CA+k3eCRJho42cYGG1OfHvRg1CdTH3W8peFHnZtFrsB5Fsvru2A@mail.gmail.com> <D8EA88AE-55D1-498E-BAE4-022B7139E0E1@lodderstedt.net>
In-Reply-To: <D8EA88AE-55D1-498E-BAE4-022B7139E0E1@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 30 Sep 2019 10:14:45 -0600
Message-ID: <CA+k3eCQbuNkkDiVdQZJGS=yp+jiTRjSSdhDe89h8s4JiX1JMOA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008911ec0593c78966"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7Aq4MDTHwZ0ObmeXc8IOsShQNr4>
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 16:15:11 -0000

That's certainly an option that could be considered. Trying to reuse some
of JAR with request_uri makes a certain amount of sense. But maybe it's
more baggage than it's worth.

On Mon, Sep 30, 2019, 9:59 AM Torsten Lodderstedt <torsten@lodderstedt.net>;
wrote:

> What if PAR would use another parameter? It could even return the actual
> authorization URL.
>
> > On 30. Sep 2019, at 08:45, Brian Campbell <bcampbell=
> 40pingidentity.com@dmarc.ietf.org>; wrote:
> >
> >
> >
> > 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 [RFC3986
> > ] that
> >       points to the Request Object (
> > Section 2.1
> > ) that holds
> >       authorization request parameters stated in
> > section 4
> >  of OAuth 2.0
> >       [
> > 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._______________________________________________
> > 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._