Propose a method for scope-based capability reduction

[jbasney]

This is my write-up of a request that CILogon has received from Fermilab with respect to our support for WLCG tokens. Interested in feedback from the group on this method.

[DrDaveD]

The use case for this is to discover what claims are available to an individual user, which only the issuer knows. For example with Vault, the scope requests will be encoded into the Vault configuration for issuer and role, and the same set of scopes is used by all users that are authorized for that issuer and role. Vault doesn't know what scopes are allowed for each user, but the issuer does.

[DrDaveD]

The discussion in today's meeting raised some objections that using / in the request may conflict with the previously defined meaning for that, and a suggestion was to replace it with /*.

[msalle]

The discussion in today's meeting raised some objections that using / in the request may conflict with the previously defined meaning for that, and a suggestion was to replace it with /*.

I think the objections raised were more about the response returning scope claims that were not explicitly asked for. /* (although not used in the original document) would still have that same issue. I'm actually not sure what OAuth2 intends AuthZ servers to do there. It says in https://tools.ietf.org/html/rfc6749#section-3.3 that the AS may fully or partially ignore the requested scope parameter, but this is more about changing the value to something else.

[maarten-litmaath]

I think the essence of the use case can be expressed as follows: give me what I am entitled to, without me having to determine my very entitlements beforehand from some other source. Such another source would duplicate crucial information.

[hannahshort]

I agree with Maarten, and in that way it's very similar to the other PR.

[DrDaveD]

Note that we are not asking for "give me all entitled scopes". The client in this case does ask for the desired scopes by name, but it does not know the extent of the allowed capabilities indicated by the paths in those scopes. This is specifically a feature for capability-based scopes, and it's not very surprising if standards do not yet address that.

[maarten-litmaath]

I think the essence of the use case can be expressed as follows: give me what I am entitled to, without me having to determine my very entitlements beforehand from some other source. Such another source would duplicate crucial information.

A certain amount of duplication of information looks unavoidable, just as we have it today with VOMS. For example, a production manager has to know that e.g. Role=production needs to be requested, or it could be hardcoded in some production tool, but in either case it is known outside VOMS. That said, it would be good to try and limit as much as possible what has to be known elsewhere to be explicitly supplied in requests to IAM. That is, it would be good if IAM could "fill in the blanks" when and where it can...

[paulmillar]

If I've understood correctly (not guaranteed!) it might be helpful to rephrase this somewhat.

The user (or some agent acting on behalf thereof) wishes to have tokens to perform some activity. That might be "analysis", "production", "skimming" or whatever labels we might wish to give those actions. Based on those labels, the OP issues a token that authorises some subset of all possible activities for that user. That is to say, the token could authorise everything the user is entitled to do, or it might be some proper subset.

It seems to me (perhaps wrongly) that the problem here is that the same language is being used both to describe the desired activity of the user (or agent thereof) and also what operations are allowed. For those within the VOMS world, this has become natural. We talk about Role=production as voms-proxy credentials used within certain work-flows. However, as Maarten points out, it does lead to duplication of knowledge: you have to know what to ask for.

Perhaps this problem might be easier to understand (and perhaps handled better) if we had a clearer separation between these two concepts. For example, the request could come with desired scopes defined using one language (e.g., work-flow:production), but the OP resolves these into scopes that the individual services then understand.

[andreaceccanti]

The problem IIUC is that you are trying to use the capabilities for a use case where identity and group-based authorization would work better (like access to home directories).

The profile already defines a mechanism to request conditional group membership, so that users can choose the "hat" they want to wear for a particular session. This decision cannot be delegated to a component in the middle of chain (i.e. vault), but must be part of the user request (as it is done today with VOMS and explicit role selection).

[DrDaveD]

The last 2 comments are more relevant to the other PR #6, I believe. The PR we are commenting on here is more focused on a different aspect, that of requesting all capabilities known by the token issuer/OP for the given user. It is true that the other PR is related to this one but I think it would be better if we kept the discussions separate. I will copy them there to reply.

[DrDaveD]

This PR was discussed after the meeting today for those who could stay and it was suggested that this additional mechanism was not needed and it could instead be done using the mechanism of PR #6. See this comment for details.

[hannahshort]

Overtaken by capability set discussion