Hello all-- Please respond to these email threads before Monday's ad hoc if you can!

This is one of our very oldest issues. In the meantime, as the most recent comment in the issue thread hints at (and we even discussed further today in the context of issue #277), in UMA2 we've done a heck of a lot of work on set math and the resource/scope ecosystem, such that -- for example -- the RS is able to request multiple permissions if it sees fit based on what groups of resources the client is likely to want access to, and we even recommend that this be part of the API documentation.

This doesn't have to be based on any special knowledge of what policy-setting opportunities actually exist at the AS, but special public-API profiles could ultimately result in extra-smart AS's doing something knowledgeable with the information. (We and the HEART group have talked about this some.)

So, some options are:

1. Do nothing normative and count this as well covered by existing mechanisms and recommendations for profiling
   
• Discussion: We have a way for the RS to handle complex resource structure now, without the AS getting involved. It potentially limits sophisticated policy options, unless a profile is being used that makes the AS "smarter" or a third-party extension is used that adds to what the RS is passing in.
  
2. Invent some mechanism for enabling the RS to teach the AS explicitly about complex resource structure
• Discussion: This could enable cross-AS interop features and additional policy-setting options. But it's invasive to the current design, and maybe it's better to let the need percolate up through more experience. (E.g., maybe a graph structure vs. hierarchy is best. :-) )
  
3. Or some other option(s) I'm not thinking of yet?...