> On 8. Oct 2019, at 16:49, George Fletcher <gffletch=40aol....@dmarc.ietf.org>
> wrote:
>
> 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?That’s the intended way to go. Do you have an idea how we could convey that even better in the text? > 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 <jric...@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 <bcampb...@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 <jus...@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 <gffle...@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-dra...@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" <i...@justin.richer.org>, "Torsten Lodderstedt" >>>>>> <tors...@lodderstedt.net>, "Brian Campbell" <bcampb...@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. >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> _______________________________________________ >>> 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. >> >> >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
