Great, thanks for the feedback. In working with Nancy on HEART stuff this weekend, I found that this rhetorical work was helping. Note that in RReg 02 (and actually in Core 09 as well), this got morphed a bit further to this formulation: "Any one resource that the resource server has registered for protection MAY consist, from the resource server's perspective, of multiple parts, or have dynamic elements such as the capacity for querying or filtering, or otherwise have internal complexity. It alone is responsible for maintaining the necessary mappings between these complex representations (which might be expressed, for example, as different requests coming from the client) and the single resource identifier known to the authorization server." We might want to go back and make this more active-voice, as in the original below. ("The resource server MAY register for protection a single resource that, from its perspective, has multiple parts...") *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Mon, Nov 28, 2016 at 10:01 AM, Justin Richer wrote:

As usual, it’s a terminology issue at its core. “Resource” in the OAuth world is an API, not a document or a URL. I’m fine with adding the MAY below, as it’s implied in the nature of the protocol.

— Justin

On Nov 18, 2016, at 6:17 PM, Eve Maler wrote:

I realized that we had an unstated MAY here. Instead of trying to squish the statement into the RReg "protected resource" definition as before, I've now broken this out into a paragraph in RReg Sec 2, Resource Registration, as follows:

"A resource server MAY register and manage as a single protected resource a set of digital data or API endpoints that, from its perspective, consists multiple parts, has dynamic elements, or otherwise has internal complexity; it alone is responsible for maintaining any required mappings between this complexity and the resource identifier known to the authorization server."

This is something that, in fact, the HEART group has been facing in its discussions about the FHIR API, and other APIs that are working on UMA protection will face it as well (though FHIR has the worst of it since it's a complex API).

Let me know what you think.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma