Hello, Thank you for your feedback, I'll add some precision then
Le 2021-01-13 à 16 h 51, Justin Richer a écrit :
I think this is an interesting approach, but I’m not sure about a few things: - What’s the utility of linking to a scope. Why require both structures to be interpreted together like that?
Linking a rar to a scope is not mandatory, i.e. if a rar type has no scope, then the type will be available for every request and every user.
That said, in Glewlwyd, the access level is the scopes. A user "has" a set of scopes which can be granted or not during authorization requests. Therefore if the client requests scopes and some are not available for the user, the grant will be limited to the ones available.
The rar types are another type of access levels, therefore I assume that a rar type can be unavailable for a user, so I allow to bind a rar type to the scopes for that purpose. But that's a design choice.
- There will absolutely be implementations that do not limit which RAR types (or even values) the client is allowed to send, much like there are implementations today that don’t restrict scopes on a per-client basis. - I don’t think that we can say the AS doesn’t verify “extra required properties”, since the AS can (and arguably should) know about the details of the “type” being used, and enforce internal consistency and structure.
I agree, but the specs doesn't mandate, allow, nor forbid anything about the extra properties. Assuming that, I didn't want the admin to have to use a hardcoded rar structure, and because this implementation is a first shot, I didn't want to complicate the rar type configuration, which could be dangerous to implement. Other part of the application are very customizable and were painful to implement.
I don't allow a client to upgrade the grant access via the refresh token, only the same grant access. Therefore to be consistent, the client can't change the rar request during a refresh, and the new access token will have the same rar content as the one granted during the authorization.It’s always up to the AS to determine what the granted access is, whether it’s for a new token, a limitation of existing grant (via refresh token), or a client asking for something “additional” for whatever purpose.
Yes, if we use a rar reduced only to what's required in the specs, then a rar type has no more information than a scope, so the advantage of rar lies beyond the mandatory parts of the specs.Also, in the draft specification, the only mandatory element type in a rar is the "type" element. In my point of view, this means that the business logic is mostly defined by the RS, rather than the AS.Just like “scope” in OAuth, it’s ultimately enforced by the RS, but the AS works in the process to interpret and potentially modify the meaning of the scope.
But to have a usable rar, the triad client-AS-RS must previously agree to use rar types defined outside of the specs.
This is not necessary a disadvantage though.
Therefore, for a client implementation to be compliant with the specs, there's not much to do: add as a parameter a JSON array with objects containing at least one "type" string property in it.Yup — and even more, most clients will be sending in static or templated values that the developers get from documentation, much like they do with scopes in APIs today. Keeping it simple for clients is definitely a goal!
Ack
I used the name extension because the first example I had in mind is the extensions and protocols describe in the websocket specs, but I don't mind the name that should be used.3 - Extensions I believe one way to mitigate these limitations is to allow extensions to be defined on top of the rar specifications. An extension can be declared like this: "RAR Extension XYZ: A rar whose type is XXX - Actions available: YYY, ZZZ or AAA - datatypes possibles: BBB, CCC, DDD or EEE - additional elements mandatory: an array of FFF and an object of GGG to represent access to some" Like this, if the AS, the RS and the client agree on using a rar extension, they can have at least a detailed pattern on what to expect in the rar type.I like that structure, but not for “extensions” exactly; more properly, I think this can be some guidance on how to create a RAR “type” definition. This fits with the philosophy of “type” defining what’s allowed to go in the object, but it would allow for a more formal definition of what that connection is. Should this be normative, or just informative, though? I’m not sure yet — I will try to come up with some proposed text on that and propose a PR.
Describing the rar types normalization structure is what I think could be improved, at least specifying how it should be normalized and for what purpose.
/Nicolas
OpenPGP_0xFE82139440BD22B9.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
