<div dir="ltr">The UMA group's rationale for calling it "resource set" was that the resource server is authoritative for any internal structure (or lack thereof) and content of a digital resource that is under UMA protection; whatever detail it <i>doesn't</i> register with an authorization server is invisible to the authorization server, so the name is an acknowledgment that the thing registered might represent multitudes (e.g., it could be a "folder of photos" for which the resource server has chosen not to register individual photos, or whatever).<div><br></div><div>We do, unfortunately, go back and forth a bit between "resource set" and "protected resource" in the two UMA-related specs, and also issue this caution in the RSR spec: <i>"Note carefully the similar but distinct senses in which the word "resource" is used in this section. The resource set descriptions are themselves managed as web resources at the authorization server through this API."</i> Because the phrase "protected resource" is so prevalent in the OAuth world, in our current work, we may consider doing some terminology alignment.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">







<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>Sydney, London, and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Aug 2, 2016 at 7:52 AM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Resource Set  - what purpose it might serve. </div><div><br></div><div>Mind you - I don't know the thinking behind the UMA spec - but In the federated authentication environment when you are dealing with hundreds if not thousands for partners, a methods to group claims together has evolved to help ease the burden on the backend  for those having to configure release policies for each and every partner.   The ability for a RS to define resource sets that makes sense for their business - may have a similar effect.<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div>
</blockquote></div><br></div></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>