I created a pull request with some proposed language here: https://github.com/oauthstuff/draft-oauth-rar/pull/52 <https://github.com/oauthstuff/draft-oauth-rar/pull/52>
— Justin > On Jul 20, 2020, at 7:42 AM, Justin Richer <jric...@mit.edu> wrote: > > Since this is a recommendation for namespace, we could also just say > collision-resistant like JWT, and any of those examples are fine. But that > said, I think there’s something particularly compelling about URIs since they > have somewhat-human-readable portions. But again, I’m saying it should be a > recommendation to API developers and not a requirement in the spec. In the > spec, I argue that “type” should be a string, full stop. > > If documentation is so confusing that developers are typing in the wrong > strings, then that’s bad documentation. And likely a bad choice for the > “type” string on the part of the AS. You’d have the same problem with any > other value the developer’s supposed to copy over. :) > > I agree that we should call out explicitly how they should be compared, and I > propose we use one of the handful of existing string-comparison RFC’s here > instead of defining our own rules. > > While the type could be a dereferenceable URI, requiring action on the AS is > really getting into distributed authorization policies. We tried doing that > with UMA1’s scope structures and it didn’t work very well in practice (in my > memory and experience). Someone could profile “type" on top of this if they > wanted to do so, with support at the AS for that, but I don’t see a > compelling reason for that to be a requirement as that’s a lot of complexity > and a lot more error states (the fetch fails, or it doesn’t have a policy, or > the policy’s in a format the AS doesn’t understand, or the AS doesn’t like > the policy, etc). > > And AS is always free to implement its types in such a fashion, and that > could make plenty of sense in a smaller ecosystem. And this is yet another > reason that we define “type” as being a string to be interpreted and > understood by the AS — so that an AS that wants to work this way can do so. > > — Justin > > PS: thanks for pointing out the error in the example in XYZ, I’ll fix that > prior to publication. > >> On Jul 18, 2020, at 8:58 PM, Dick Hardt <dick.ha...@gmail.com >> <mailto:dick.ha...@gmail.com>> wrote: >> >> Justin: thanks for kindly pointing out which mail list this is. >> >> To clarify, public JWT claims are not just URIs, but any collision-resistant >> namespace: >> "Examples of collision-resistant namespaces include: Domain Names, Object >> Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 >> Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]." >> >> I think letting the "type" be any JSON string and doing a byte-wise >> comparison will be problematic. A client developer will be reading >> documentation to learn what the types are, and typing it in. Given the wide >> set of whitespace characters, and unicode equivalence, different byte >> streams will all look the same, and a byte-wise comparison will fail. >> >> Similarly for URIs. If it is a valid URI, then a byte-wise comparison is not >> sufficient. Canonicalization is required. >> >> These are not showstopper issues, but the specification should call out how >> type strings are compared, and provide caveats to an AS developer. >> >> I have no idea why you would think the AS would retrieve a URL. >> >> Since the type represents a much more complex object then a JWT claim, a >> client developer's tooling could pull down the JSON Schema (or some such) >> for a type used in their source code, and provide autocompletion and >> validation which would improve productivity and reduce errors. An AS that is >> using a defined type could use the schema for input validation. Neither of >> these would be at run time. JSON Schema allows comments and examples. >> >> What is the harm in non-normative language around a retrievable URI? >> >> BTW: the example in >> https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2 >> <https://oauth.xyz/draft-richer-transactional-authz#rfc.section.2> has not >> been updated with the "type" field. >> >> >> >> On Sat, Jul 18, 2020 at 8:10 AM Justin Richer <jric...@mit.edu >> <mailto:jric...@mit.edu>> wrote: >> Hi Dick, >> >> This is a discussion about the RAR specification on the OAuth list, and >> therefore doesn’t have anything to do with alignment with XAuth. In fact, I >> believe the alignment is the other way around, as doesn’t Xauth normatively >> reference RAR at this point? Even though, last I saw, it uses a different >> top-level structure for conveying things, I believe it does say to use the >> internal object structures. I am also a co-author on RAR and we had already >> defined a “type” field in RAR quite some time ago. You did notice that XYZ’s >> latest draft added this field to keep the two in alignment with each other, >> which has always been the goal since the initial proposal of the RAR work, >> but that’s a time lag and not a display of new intent. >> >> In any event, even though I think the decision has bearing in both places, >> this isn’t about GNAP. Working on RAR’s requirements has brought up this >> interesting issue of what should be in the type field for RAR in OAuth 2. >> >> I think that it should be defined as a string, and therefore compared as a >> byte value in all cases, regardless of what the content of the string is. I >> don’t think the AS should be expected to fetch a URI for anything. I don’t >> think the AS should normalize any of the inputs. I think that any >> JSON-friendly character set should be allowed (including spaces and >> unicodes), and since RAR already requires the JSON objects to be >> form-encoded, this shouldn’t cause additional trouble when adding them in to >> OAuth 2’s request structures. >> >> The idea of using a URI would be to get people out of each other’s >> namespaces. It’s similar to the concept of “public” vs “private” claims in >> JWT: >> >> https://tools.ietf.org/html/rfc7519#section-4.2 >> <https://tools.ietf.org/html/rfc7519#section-4.2> >> >> What I’m proposing is that if you think it’s going to be a general-purpose >> type name, then we recommend you use a URI as your string. And beyond that, >> that’s it. It’s up to the AS to figure out what to do with it, and RAR stays >> out of it. >> >> — Justin >> >>> On Jul 17, 2020, at 1:25 PM, Dick Hardt <dick.ha...@gmail.com >>> <mailto:dick.ha...@gmail.com>> wrote: >>> >>> Hey Justin, glad to see that you have aligned with the latest XAuth draft >>> on a type property being required. >>> >>> I like the idea that the value of the type property is fully defined by the >>> AS, which could delegate it to a common URI for reuse. This gets GNAP out >>> of specifying access requests, and enables other parties to define access >>> without any required coordination with IETF or IANA. >>> >>> A complication in mixing plain strings and URIs is the canonicalization. A >>> plain string can be a fixed byte representation, but a URI requires >>> canonicalization for comparison. Mixing the two requires URI detection at >>> the AS before canonicalization, and an AS MUST do canonicalization of URIs. >>> >>> The URI is retrievable, it can provide machine and/or human readable >>> documentation in JSON schema or some such, or any other content type. Once >>> again, the details are out of scope of GNAP, but we can provide examples to >>> guide implementers. >>> >>> Are you still thinking that bare strings are allowed in GNAP, and are >>> defined by the AS? >>> >>> >>> >>> On Fri, Jul 17, 2020 at 8:39 AM Justin Richer <jric...@mit.edu >>> <mailto:jric...@mit.edu>> wrote: >>> The “type” field in the RAR spec serves an important purpose: it defines >>> what goes in the rest of the object, including what other fields are >>> available and what values are allowed for those fields. It provides an >>> API-level definition for requesting access based on multiple dimensions, >>> and that’s really powerful and flexible. Each type can use any of the >>> general-purpose fields like “actions” and/or add its own fields as >>> necessary, and the “type” parameter keeps everything well-defined. >>> >>> The question, then, is what defines what’s allowed to go into the “type” >>> field itself? And what defines how that value maps to the requirements for >>> the rest of the object? The draft doesn’t say anything about it at the >>> moment, but we should choose the direction we want to go. On the surface, >>> there are three main options: >>> >>> 1) Require all values to be registered. >>> 2) Require all values to be collision-resistant (eg, URIs). >>> 3) Require all values to be defined by the AS (and/or the RS’s that it >>> protects). >>> >>> Are there any other options? >>> >>> Here are my thoughts on each approach: >>> >>> 1) While it usually makes sense to register things for interoperability, >>> this is a case where I think that a registry would actually hurt >>> interoperability and adoption. Like a “scope” value, the RAR “type” is >>> ultimately up to the AS and RS to interpret in their own context. We :want: >>> people to define rich objects for their APIs and enable fine-grained access >>> for their systems, and if they have to register something every time they >>> come up with a new API to protect, it’s going to be an unmaintainable mess. >>> I genuinely don’t think this would scale, and that most developers would >>> just ignore the registry and do what they want anyway. And since many of >>> these systems are inside domains, it’s completely unenforceable in practice. >>> >>> 2) This seems reasonable, but it’s a bit of a nuisance to require >>> everything to be a URI here. It’s long and ugly, and a lot of APIs are >>> going to be internal to a given group, deployment, or ecosystem anyway. >>> This makes sense when you’ve got something reusable across many >>> deployments, like OIDC, but it’s overhead when what you’re doing is tied to >>> your environment. >>> >>> 3) This allows the AS and RS to define the request parameters for their >>> APIs just like they do today with scopes. Since it’s always the combination >>> of “this type :AT: this AS/RS”, name spacing is less of an issue across >>> systems. We haven’t seen huge problems in scope value overlap in the wild, >>> though it does occur from time to time it’s more than manageable. A client >>> isn’t going to just “speak RAR”, it’s going to be speaking RAR so that it >>> can access something in particular. >>> >>> And all that brings me to my proposal: >>> >>> 4) Require all values to be defined by the AS, and encourage specification >>> developers to use URIs for collision resistance. >>> >>> So officially in RAR, the AS would decide what “type” means, and nobody >>> else. But we can also guide people who are developing general-purpose >>> interoperable APIs to use URIs for their RAR “type” definitions. This would >>> keep those interoperable APIs from stepping on each other, and from >>> stepping on any locally-defined special “type” structure. But at the end of >>> the day, the URI carries no more weight than just any other string, and the >>> AS decides what it means and how it applies. >>> >>> My argument is that this seems to have worked very, very well for scopes, >>> and the RAR “type” is cut from similar descriptive cloth. >>> >>> What does the rest of the group think? How should we manage the RAR “type” >>> values and what they mean? >>> >>> — Justin >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> > > _______________________________________________ > 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
