How are client-contributed scopes mapped to resources during authorization assessment?

[xmlgrrl]

@nynymike and Yuriy asked how a client-preregistered and -requested scope is supposed to be bound to resources. Does it get bound to resources in the permission ticket?

Though I think the example in Grant Sec 3.3.4 sort of makes the logic sort of clear, we need to be much clearer (and take the mystery away for implementers). Here was my attempt at a quick restatement:

• The client's resource request at the RS turns into an explicit RS permission request (which maps scopes to resource IDs).
• Any explicit client scope request at the AS, as long as it's paired with client pre-registration of the same scope at the AS beforehand, gets treated as an "expansive match" allowing that scope to be counted as a candidate granted scope with any resource that appears in the permission ticket.

For the sake of completeness, here's a full rationale:

• The permission ticket is the obvious target involved in the calculation which has a set of scope-bound resources.
  • It wouldn't make sense to map any such scope to the set of all resources registered at the AS because that set is irrelevant for the task at hand.
  • Nor would it make sense to map it to the much smaller set of "resources relevant to the RO's policy conditions for this scope" because that's what the AS is about to look at in a moment.
  • There is no other definable set of resources I can think of.
• The reason it's an expansive match is that the boundedness of scopes to resources is opaque to the client.
  • Making the match any tighter, or any more complex, is unrealistic and "unfair" to the client; this rule tracks what we say about recommending that the RS document its API and scopes.

Do we agree that's correct?

[nynymike]

Yes, I think the clarification is helpful.

[ciseng]

Yes, I think that helps too.

[jricher]

This is inline with my interpretation as well -- it adds scopes to the existing resource requests.