I like this idea.

It would essentially translate this user facing feature into a common language that we can use in Keycloak for future implementations such as RAR and GNAP authorization primitives.

Considering how GNAP, which also implements RAR as its main authorization mechanism, handles Scopes by adding them to the RAR authorization data object, we could most likely support both use cases by implementing the most simple RAR features.

I'm thinking about doing a new design proposal merging both, just to verify whether we could solve both use cases with a single implementation.

I totally agree with the a,b,c,d wrap up and with supporting two representations (Dynamic scopes and RARs) with the same processing logic.

Here is one option how Keycloak could receive dynamic scope values and translates them into a RAR Authorization data element also called authorization details object.

Scope "group:group-a" is translated to

{
  "type": "group",
  "identifier":"group-a"
}

A handler fro the type "group" would work with the identifier value "group-a" as input. It would also be free to further parse the identifier, if some custom dynamic scope syntax is are required to be accepted.

A RAR request like this

{
   "type": "account_information",
   "actions": [
      "list_accounts",
      "read_balances",
      "read_transactions"
   ],
   "locations": [
      "https://example.com/accounts"
   ]
}

could also be sent as scope with URL encoded JSON after the type prefix:

account_information:%7B%0A%20%20%20%22type%22%3A%20%22account_information%22%2C%0A%20%20%20%22actions%22%3A%20%5B%0A%20%20%20%20%20%20%22list_accounts%22%2C%0A%20%20%20%20%20%20%22read_balances%22%2C%0A%20%20%20%20%20%20%22read_transactions%22%0A%20%20%20%5D%2C%0A%20%20%20%22locations%22%3A%20%5B%0A%20%20%20%20%20%20%22https%3A%2F%2Fexample.com%2Faccounts%22%0A%20%20%20%5D%0A%7D

Keycloak could recognize the JSON (starting with %7B) after the registered type "account_information" or prefix "account_information:". The JSON is send as authorization details object to the registered authorization details handler.

Note 1:
Scope values can become very long this way. Clients could switch to pushed auth requests (PAR) still using scopes, then the
length of scopes is not an issue so much. Or they could switch to RAR and PAR. It is a good to keep this choice up to the clients and to support all in parallel by the authorization server.

Note 2:
Built-in Keycloak RAR type handlers which provide user data (Keycloak as resource server) would probably use an URI as type, e.g. "http://keycloak.org/auth-type/group".
This is suggested at GNAP - 8. Resource Access Rights
https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-07.html#section-8

This is interesting consideration. I agree that internally will be great to consider scope and authorization_details in some structure like you proposed. However I think that it would be still good if Keycloak consider whether the particular request was sent via the dynamic scope (via scope parameter) or via authorization_details .

There is grant management specification, which considers that client can query the AS about the consent and AS is supposed to return the structure with both scope and authorization_details. See example https://openid.net/specs/fapi-grant-management-01.html#section-6.4 . Note that AS needs to differentiate whether particular request was sent with scope or with authorization_details .
Based on this, it looks better to me if it is defined that specific type (EG. payment) is supposed to be requested by client via authorization_details when other types (EG. group) can be requested by client via scope. Not sure if there is any real benefit of being able to reference for example type group by both scope and authorization_details ?

Overaly I think that scope is supposed to be used for shorter thinks like group:123 when authorization_details is supposed to be used for JSON structure and hence usually RAR will be used together with PAR.

Thank you for your feedback, the consideration above is mainly about handler implementations, that need to process a rich authorization object only, while originally a (Dynamic) Scope like "group:123" was requested. Keycloak of cause should keep track of the original request format, so that https://openid.net/specs/fapi-grant-management-01.html#section-6.4 could be implemented.

In addition it is about the client being free to decide to request via scope or via RAR, while at Keycloak there would be only one handler registered which can process the type.
Especially for short scopes like group:123 existing clients may prefer scopes. If more details are involved like payment the client could still use a scope according to the transformation pattern outlined above (URL encoded JSON). But probably the client needs to switch to Scope with pushed auth request (PAR) or PAR+RAR, if URL gets to long.

I like this idea. Parsing the dynamic scopes would be a pre-step in the authorization handling pipeline. By "translating" a dynamic scope into an authorization_details representation, the rest of the code can work with that canonical format, and just keep track of the original request format for further presentation and processing.

On a related note, it would also be nice to have an API (to be used from within providers) to query for requested scopes and to grant/deny (activate/deactivate) them on the fly.

@dteleguin Can you please add some example how this API can be used and how it will look like? I suppose that you mean something different, then the Grant Management API specification, which is supposed to be used by clients to interact with AS as specified here:
https://openid.net/specs/fapi-grant-management-01.html
https://github.com/keycloak/keycloak-community/pull/265/files
?