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 <jric...@mit.edu
<mailto: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 <mailto: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
<mailto: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 <mailto: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
<mailto: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
<mailto:i...@justin.richer.org>>, "Torsten Lodderstedt"
<tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>, "Brian Campbell"
<bcampb...@pingidentity.com
<mailto: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 <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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
