hi dave, i see what you are saying:
it's the provider that associates those resource-id's with the client, as in:
<oauth:client client-id="tonr" resource-ids="sparklr" authorized-grant-types="authorization_code" authorities="ROLE_CLIENT"
scope="read,write" secret="secret" />
so as long as the client and it's associated resource-id's remains constant, including both in the key is redundant.
now that i'm looking at it, it's not obvious to me how resource-id's are used by the provider.
i see that they can be called out in this config:
<oauth:resource-server id="resourceServerFilter" resource-id="sparklr" token-services-ref="tokenServices" />
and they end up being referred to by OAuth2ProtectedResourceFilter, but thinking forward to dynamic client registration, it's not clear to me how it all fits together.
for instance, will a client be given a pick list of resource-id's at registration time, etc?
i agree though that the topic of resource-id's can arguably be separated from this issue.
i'll find a better place to continue the discussion
thanks again for your help on this!