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> 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
