Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.txt
George Fletcher <gffletch@aol.com> Tue, 08 October 2019 14:49 UTC
Return-Path: <gffletch@aol.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 F02A6120883 for <oauth@ietfa.amsl.com>; Tue, 8 Oct 2019 07:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=aol.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 sDzF-gKsor2w for <oauth@ietfa.amsl.com>; Tue, 8 Oct 2019 07:49:53 -0700 (PDT)
Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 E241C120878 for <oauth@ietf.org>; Tue, 8 Oct 2019 07:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1570546189; bh=K3t6aKV6kRHGhVbdjMOoZAaWZGjSoYbJaVIqxvXRGeo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=q//Aw2dj28BlwK2pudPuUUte9GLbUzX+s2MdcSH25ymc3QuuANuueHQUsp425PJmg061arJvPuIJRJkHq24vajE4NBAU7c6IoaviLb0FYn1DfResfYq8XQOZhFYhapw3Iqstm0m8BLaMiZ+YJEgQdhoHmzwjjqcXh6xgU/4PytfSNeLgKCKsESYJe7LcOSRpwUQNMUdH/Fudlm7wbsN9GjPFd6dPxwlOC06uRY/cId2V0moUYMiX6jC8tkbYDpFSJ3TQ42a1ShvnJfG8KyIedoyvAMf7148D+Vj8zgql5tP+TyzGQ58taxetfW8qhfAa6HG3j2WgbACNPqwocamLLQ==
X-YMail-OSG: VmOF2LcVM1l..c6V_urAnMYMKGRsYOcj7xdHr2q2rgg7os8gdvQIku3w6hwBvb3 UIC68GzCdOTDIpM0hH.1V1DfuoYv6dzO9Y1Pbc3SeT5DZ5hMEUJxseH1zhqeXof7N3B2Dl_utIr0 v7PbVdlS6GLT9xbh4zbwVez3WJQ7AiYsiY_xzs8H7FY3zRK4ulri3yxQTFhUO90bIDLpc6ZWpPBG UwyM27yfjWPfmfh1oHw8npDcdDs56AGAEx_kpNQTZF.Z.5Ni0003tEnF2GOTheZ_9pEfABwwxP7K q_UhjrD9LUmS0N3ET8JGZWtLfKUGc0vPG.mH2AdF.wjvFtApFqMgPMQSiTU1XzE5M6t7Q7oxfdgg TnblyPeGDtSJLC5p_EseHt7fXodUPkgffWg__6_opL_2_9V_WF.jUU1nLLm_qIzQehOcY5XB1hcl 0njGf1LhQfo6qgZLr2mrq_a.KKqky0AIcIx1z5Get2MNlwT1BcrugcJaj9r0TY7YB2Oo20Nmo_X7 3fP0XcDIpQmdJT.UbNZ33MG6Tf8daJvXTicfLKpXbds.H5wJ7WAwaGnAHVF0CNKctlRycpUC7EKZ 4JhRmy4AHQDt5XksBbeqlIi2V8wKFRYlSnFpqe8HdpTkL6IQesAugU.DnLWjd9NkKDgfE8XjyI5Y zw8dxVwgdz3MfSigZdlqz7RBo9TBYEHRJUkhS7T2mxLhMTXjPWa.JKx.rzjs.joUEcgr6ZcDnxd0 w_GjH0k08C3AhabRENIn56Ct67T75hR_wvNcgO2iZsOCbKu9aSzDDk5HJyAgMeHgc64SONrkevI8 KkwMt1zH7MrcOoTOWx3Ktx_CZUWwtUAQGkpfTmcpUdG9itDLSK094FdJfPuo3l3gsBOQHlDwH8YO 71h1Puqr1G0bwhsWQ_o_y9aEu7reNEoTLub89k1RUm7MX8gz.k2oPOkZtxuOZGnhTsvGyABMsWAU GAA8fqYOjwSSjkTu3OTWpI5pLLtFaVllL9DH1Np2G2Uh6gJXEM0AZBgUZnxxbmZw342dJC1gk2GZ u6OLEc.BvfCkTvf5xM5XHO1PahiCXJGi13Ad_psSKjPvM0SwKysHYW46nWD9n.jL.iXlUGt7BX.S 4WT.pIDNhrLxP5tKXmczN9C_xVBILSh1M6nh97KjsRvQyxZQmdXu6k_fhBupPNKohXkt5xunm9me UQ5KdyyVbKhvZ6LFF56f.kQ.5JlteyikRkENg2CJ3gUItQ.905HKOyg6v1G0xxX8Q_BVDeXIIjue P2xDj5sovBgdfIxzW4zp.AKPjz4Y82ygwmw2UG6fkCa.vCkqkpykXsZwrJXmOkaRvhwI0mLD.jtu j_6oagrgxqFjGrA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Oct 2019 14:49:49 +0000
Received: by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 862aa4e7f60c29114def36585dbec3ad; Tue, 08 Oct 2019 14:49:44 +0000 (UTC)
To: Brian Campbell <bcampbell@pingidentity.com>, Justin Richer <jricher@mit.edu>
Cc: oauth <oauth@ietf.org>
References: <156907504831.22964.1710780113673136607.idtracker@ietfa.amsl.com> <A82AA337-86BF-485D-901B-3A3C73C6177B@lodderstedt.net> <e4427073-f995-4337-ca7c-99a92c745bf2@aol.com> <CBCF41AA-CADB-4CF9-8BB4-172E4571B655@bspk.io> <CA+k3eCS1Zgoj6UStsQDu=8y5EZioqU5hTysokYPpkZr0dAxhPA@mail.gmail.com> <5AD68F4C-837A-4532-97D1-1FE65FEC32D2@mit.edu> <CA+k3eCT=YGspG9sgXnV1B+6ZMJCQGUJiuWW0L12tPoddqHnrvg@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <14e645b7-3667-5cd6-5480-d9b7bbeaf888@aol.com>
Date: Tue, 08 Oct 2019 10:49:31 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCT=YGspG9sgXnV1B+6ZMJCQGUJiuWW0L12tPoddqHnrvg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------585333E9228E7E2201E367AD"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/OlUbWcngD_I9rGavHKSTIUdg91Q>
Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-rar-02.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: Tue, 08 Oct 2019 14:49:57 -0000
In general, it's difficult to determine how to extend for new types or if they should be wrapped up in "data" somehow. |{ "type":"https://example.com/my_field", "actions":[ "read" ], "my_field": { "id": "<id_value>" } }| I'm assuming the above is perfectly legit and the intended way for the spec to be extended? If not, what is the expected extension mechanism? Thanks, George On 10/2/19 11:45 AM, Brian Campbell wrote: > I guess we differ in our opinion of how remiss that would be. But > given what you've got in there now, the more narrow point I was trying > to make was to say that I don't think "data" is defined or explained > well enough to be helpful. > > On Tue, Oct 1, 2019 at 4:33 PM Justin Richer <jricher@mit.edu > <mailto:jricher@mit.edu>> wrote: > > I think that we need to define :some: common set to data elements > in this spec, in order to help people who are using this and > trying to apply it to their APIs do so in vaguely consistent ways. > The details of which parts we standardize on are still, I think, > up for grabs. I???d be happy to have a better name than ???data??? for > this aspect, but I think there???s value in defining this kind of > thing. Like in the financial space, it???s the difference between > ???transactions??? and ???accounts???. Or in the medical space, there???s > ???demographics??? and ???appointments??? and ???testResults???. This is a > very, very, very common way to slice up OAuth-protected resources, > and we???d be remiss to leave it undefined and just have every API > developer need to come up with their own version of the same thing. > > ??? Justin > >> On Oct 1, 2019, at 2:40 PM, Brian Campbell >> <bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>> >> wrote: >> >> I'm not entirely sold on the draft attempting to define this set >> of common data elements in the first place. But that said, I >> think (similar to George?) I'm struggling with "data" more than >> the others. The definition in the -02 draft is an "array of >> strings representing the kinds of data being requested from the >> resource" and I'm honestly having a hard time understanding what >> that actually means or how it would be used in practice. And I'm >> not sure roughly equating it to ???what kind of thing I want??? >> helped me understand any better. >> >> On Tue, Sep 24, 2019 at 5:34 PM Justin Richer <justin@bspk.io >> <mailto:justin@bspk.io>> wrote: >> >> The idea behind the ???locations???, ???actions???, ???data???, and >> ???identifier??? data element types mirrors what I???ve seen >> ???scope??? used for in the wild. They roughly equate to ???where >> something is???, ???what I want to do with it???, ???what kind of >> thing I want???, and ???the exact thing I want???, respectively. >> I???m completely open for better names, and have even been >> thinking ???datatype??? might be better than just ???data??? for the >> third one. >> >> As for encoding, I think that form encoding makes sense >> because it???s the simplest possible encoding that will work. I >> personally don???t see a need to armor this part of the request >> with base64, as it is in JOSE, and doing so would make it one >> more step removed from easy developer understanding. >> >> -- Justin Richer >> >> Bespoke Engineering >> +1 (617) 564-3801 >> https://bspk.io/ >> >> >> >>> On Sep 24, 2019, at 1:45 PM, George Fletcher >>> <gffletch@aol.com <mailto:gffletch@aol.com>> wrote: >>> >>> Just two questions... >>> >>> 1. What is the rationale that 'data' is really an array of >>> arbitrary top-level claims? I find looking at the spec and >>> not finding a 'data' section a little confusing. >>> >>> 2. What is the rationale for sending the JSON object as a >>> urlencoded JSON string rather than a base64url encoded JSON >>> string? The later would likely be smaller and easier to read:) >>> >>> Thanks, >>> George >>> >>> On 9/21/19 1:51 PM, Torsten Lodderstedt wrote: >>>> Hi all,?? >>>> >>>> I just published a draft about ???OAuth 2.0 Rich >>>> Authorization Requests??? (formerly known as ???structured >>>> scopes???).?? >>>> >>>> https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >>>> >>>> It specifies a new >>>> parameter?????authorization_details"??that is used to carry >>>> fine grained authorization data in the OAuth authorization >>>> request. This mechanisms was designed based on experiences >>>> gathered in the field of open banking, e.g. PSD2, and is >>>> intended to make the implementation of rich and transaction >>>> oriented authorization requests much easier than with >>>> current OAuth 2.0. >>>> >>>> I???m happy that Justin Richer and Brian Campbell joined me >>>> as authors of this draft. We would would like to thank >>>> Daniel Fett, Sebastian Ebling, Dave Tonge, Mike Jones, Nat >>>> Sakimura, and Rob Otto for their valuable feedback during >>>> the preparation of this draft. >>>> >>>> We look forward to getting your feedback.?? >>>> >>>> kind regards, >>>> Torsten.?? >>>> >>>>> Begin forwarded message: >>>>> >>>>> *From: *internet-drafts@ietf.org >>>>> <mailto:internet-drafts@ietf.org> >>>>> *Subject: **New Version Notification for >>>>> draft-lodderstedt-oauth-rar-02.txt* >>>>> *Date: *21. September 2019 at 16:10:48 CEST >>>>> *To: *"Justin Richer" <ietf@justin.richer.org >>>>> <mailto:ietf@justin.richer.org>>, "Torsten Lodderstedt" >>>>> <torsten@lodderstedt.net >>>>> <mailto:torsten@lodderstedt.net>>, "Brian Campbell" >>>>> <bcampbell@pingidentity.com >>>>> <mailto:bcampbell@pingidentity.com>> >>>>> >>>>> >>>>> A new version of I-D, draft-lodderstedt-oauth-rar-02.txt >>>>> has been successfully submitted by Torsten Lodderstedt and >>>>> posted to the >>>>> IETF repository. >>>>> >>>>> Name:draft-lodderstedt-oauth-rar >>>>> Revision:02 >>>>> Title:OAuth 2.0 Rich Authorization Requests >>>>> Document date:2019-09-20 >>>>> Group:Individual Submission >>>>> Pages:16 >>>>> URL: >>>>> ??????????????????????https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-02.txt >>>>> Status: >>>>> ????????????????https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ >>>>> Htmlized: >>>>> ????????????https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02 >>>>> Htmlized: >>>>> ????????????https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar >>>>> Diff: >>>>> ????????????????????https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-02 >>>>> >>>>> Abstract: >>>>> ????This document specifies a new parameter >>>>> "authorization_details" that >>>>> ????is used to carry fine grained authorization data in >>>>> the OAuth >>>>> ????authorization request. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the >>>>> time of submission >>>>> until the htmlized version and diff are available at >>>>> tools.ietf.org <http://tools.ietf.org/>. >>>>> >>>>> The IETF Secretariat >>>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto: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./ > > > /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-WG] Fwd: New Version Notification for draf… Torsten Lodderstedt
- Re: [OAUTH-WG] Fwd: New Version Notification for … Janak Amarasena
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] Fwd: New Version Notification for … George Fletcher
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Aaron Parecki
- Re: [OAUTH-WG] Fwd: New Version Notification for … George Fletcher
- Re: [OAUTH-WG] Fwd: New Version Notification for … Justin Richer
- Re: [OAUTH-WG] Fwd: New Version Notification for … Aaron Parecki
- Re: [OAUTH-WG] Fwd: New Version Notification for … Brian Campbell
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell
- Re: [OAUTH-WG] Fwd: New Version Notification for … Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… George Fletcher
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Justin Richer