Grant Management Query Response

[Filip Skokan]

Under Query Status of a Grant example

scopes: JSON array where every entry contains the scope parameter value and (optionally) any resource parameter value as defined in [@!RFC8707] passed in the same authorization request. The AS MUST maintain the scope and resource values passed in different authorization requests in separate objects of the JSON structure in order to preserve their relationship.

This needs clarification. Should e.g. { "scope":"openid" } and { "scope":"profile" } be separate entries rather than { "scope":"openid profile" } if they were requested as part of two different authorization requests? How is “their relationship” preserved this way? As an implementer this MUST is problematic as it forces a specific data structure.

As a client i don’t know how i were to interpret them being separate anyway. I mean, as-is we don’t define any “addressability” for being able to revoke just a subset anyway.

The claims parameter is not handled this way, altho each claim may have also been requested separately. (claims: JSON array containing the names of all OpenID Connect claims (see [@!OpenID]) as requested and consented in one or more authorization requests associated with the respective grant.)

Suggestion: make it a MAY instead of a MUST, or (more drastically) actually require them merged and require that every resource is only listed once. Same for an entry with no “resource” property (AS’s openid defined scopes).

[Takahiko Kawasaki]

I have the same concern as @Filip Skokan has. The structure of response to Grant Management Query is arguable.

scopes requires that the relationship between scope and resources in different authorization requests be preserved in separate objects. Why isn't the same logic applied to the relationship between scope and authorization_details?

The specification requires that the scope and resource values passed in different authorization requests be maintained in separate objects. Why aren't claims in different authorization requests maintained in separate objects? To put it the other way around, why is it needed to maintain the relationship between scope and resources in separate objects while claims are cumulatively merged and are not managed as separate objects?

In general, if information in different authorization requests needs to be maintained in separate objects, the more a client repeats an authorization request with a grant_id, the more separate objects per grant_id the authorization server must maintain cumulatively without limitation.

If a grant_id can represent information in different authorization requests in separate objects, a grant_id is, in effect, equal to a list of access tokens. If it were what spec authors want, it would be better and more straightforward to define an API to get a list of introspection results about access tokens which have been issued to a particular combination of a client application and a resource owner.

[Torsten Lodderstedt]

This needs clarification. Should e.g. { "scope":"openid" } and { "scope":"profile" } be separate entries rather than { "scope":"openid profile" } if they were requested as part of two different authorization requests? How is “their relationship” preserved this way? As an implementer this MUST is problematic as it forces a specific data structure.

scopes requires that the relationship between scope and resources in different authorization requests be preserved in separate objects.

RFC 8707 states

When requesting a token, the client can indicate the desired target service(s) where it intends to use that token by way of the "resource" parameter and can indicate the desired scope of the requested token using the "scope" parameter. The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services.

so I inferred an implementation would also treat resource and scope values requested and consented in the same authorization request as belonging together, i.e. if the client requested “scope_a” at “resource_x” in authorization request 1, requesting “scope_b” at “resource_y” in request 2 would not result in the permission for “scope_b” at “resource_x”. That’s why the text currently requires to keep this data separated.

However, I just realized the AS could indeed ask the user to consent to “scope_b” at “resource_x” in the consent of the second transaction. That’s at the discretion of the AS.

Moreover, as Filip pointed out, there are (a lot of) requests with scope values only and implementation will merge those values.

Based on that realization, I suggest to ALLOW for separate objects but not require it. WDYT?

Why isn't the same logic applied to the relationship between scope and authorization_details?

https://tools.ietf.org/html/draft-ietf-oauth-rar-04#section-3.1 does not define a normative relationship defined between scope and authorization_details.

The claims parameter is not handled this way, altho each claim may have also been requested separately.

Same rationale here, I’m not aware of any normative relationship between claims and resource.

[Filip Skokan]

I specifically used { "scope":"openid" } and { "scope":"profile" } as example because they are without resource (in my head those are “OIDC OP Scopes”, not “resource” scopes.

My whole objection was to the “different authorization requests” part in different authorization requests be preserved in separate objects. If two scopes come from two requests for the same resource, they’re one member in the response for me, then if two other scopes come from two requests without a resource, i.e. they are “OIDC OP Scopes” then those are one additional member in response.

[Torsten Lodderstedt]

Ah, I got it (even if it took your second attempt :-)).

That raises another question: what if the client would request “openid email” with a resource A and “openid profile” with another resource?

[Filip Skokan]

They’re listed for each resource.

[Torsten Lodderstedt]

“openid email profile” would be good for resources 1 and 2?

[Filip Skokan]

Example

[
  {
    scope: "email scopeA-1 scopeA-2",
    resource: "A" // Resource A scopes
  },
  {
    scope: "profile email scopeB-1 scopeB-2",
    resource: "B" // Resource B scopes
  },
  {
    scope: "openid email profile" // OpenID scopes (e.g. for userinfo, id token claims)
  }
]

All i wanted to avoid is that we’d have to have, e.g. email and scopeA-1 scopeA-2 in two entries if they came from two different requests.

Essentially change

The AS MUST maintain the scope and resource values passed in different authorization requests in separate objects of the JSON structure in order to preserve their relationship.

to something along the lines of.

The AS MUST maintain the scope and resource relationship by returning multiple scopes array members for each distinguished resource (or lack thereof). The AS MAY also include multiple entries for the same resource if these were part of separate authorization requests.

‌

[Torsten Lodderstedt]

If I get it right, you are suggesting to organise scopes by resource (one could also make this a hierarchy), with the exception of openid scopes where the resource assignment is implicit.

I was meanwhile thinking about even more flexibility where the AS may decide how to organise the data.

[Filip Skokan]

I was meanwhile thinking about even more flexibility where the AS may decide how to organise the data.

Which would hurt interoperability IMHO.

[Torsten Lodderstedt]

I agree.

@Takahiko Kawasaki @Roland Hedberg @Brian Campbell @Vladimir Dzhuvinov WDYT?

[Brian Campbell]

Sometimes I regret RFC 8707…

Preserving the relationship between scope(s)/resource(s) as they were requested/approved seems necessary. But mandating that the AS “remember” each authz request distinctly oversteps too much into implementation details and data models.

Organizing by distinguished ('distinct' might be a better word?) resource or lack thereof seems logical but does run somewhat counter to the request structure allowed by RFC 8707. I.e. I’d sort of expect to see this request scope=s1+s2&resource=r1&resource=r2 as:

[{"scope":"s1 s2", "resource": ["r1", "r2"]}]

but organizing by resource would suggest something like this:

[{"scope":"s1 s2", "resource": "r1"}, {"scope":"s1 s2", "resource": "r2"}]

Maybe that doesn’t matter though as it’s just different view into the data. And requests with multiple resources are probably rare anyway.

Regardless, it does need to account for scopes requested without a resource and for ASs that don’t support RFC 8707 at all.

[Dima Postnikov]

Discussed with Torsten and Stuart today: We decided to leave organizing scopes and resources for presentation up to AS. Once tested in the field we might have a look at this again.

[Torsten Lodderstedt]

here is a PR #271

[Torsten Lodderstedt]

PR merged