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, 8 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./