[OAUTH-WG] Rich Authorization Requests feedbacks on implementation

[Nicolas Mora <[e-mail]>]

Hello,

I've implemented Rich Authorization Requests defined in 
draft-ietf-oauth-rar-03 for Glewlwyd soon-to-be-released 2.5 [1], and I 
humbly wanted to write my feedback about this implementation to share my 
experience.

For starters, this implementation and my following feedbacks are based 
on the prism of Glewlwyd's implementation and philosophy, and my limited 
experience on OAuth2, so I appologize in advance if I write non-sense or 
big mistakes.

1 - Design

The way I saw it, there are 2 different approaches to implement oauth2 
rar: either to get a token with a more detailed scope, or to get a 
one-time token with extra grants.

Both are not exclusive, but a big difference I see between those 2 
approaches is the grant access from the user part. The second approach 
would require the user to know what extra grant is asked by the client 
every time the client asks for it, i.e. when the client redirects the 
user to the /authorization endpoint.

To be more consistent with Glewlwyd's philosophy, I chose the first 
approach, with those rules.
The AS administrator declares what rar types are allowed [2]
   - a rar type has a defined set of locations, actions, datatypes and 
enriched authorization details that the client can ask for
   - the client must be explicitly allowed to add a rar type in the 
authorization request
   - a rar type can be linked to one or more scope. In that case, the 
authorization request must include at least one of the linked scope, and 
the scope must be available for the user and the scope must be granted 
to the client
   - the client can add as many properties as required in the rar type, 
those extra properties are not verified by the AS, on access granted, 
the extra properties will be present in the "authorization_details" result.

On first use of a rar type by a client for a user, the user must grant 
to the client the rar access [3]. That's why the grant message will show 
to the user ALL access possible via this rar type
Once this access is granted or not, the user will not be asked again on 
another authorization request by the client (but is can be changed at 
any time, as a scope grant).

2 - Limitations

In this design, the AS has a limited control over the 
authorization_details content, and the trust between the AS and the 
client must be high enough so if a rar type can gain access to sensitive 
actions or information, the user should know about it.

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.

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.

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.

Any thoughts?

/Nicolas

[1] https://github.com/babelouest/glewlwyd
[2] 
https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/plugin-oidc-rar.png
[3] 
https://raw.githubusercontent.com/babelouest/glewlwyd/master/docs/screenshots/login-rar-grant.png