<div dir="ltr"><div>In Section 4. Component Registration <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html">http://openid.bitbucket.org/HEART/openid-heart-uma.html</a> "The authorization server MUST allow for <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html#RFC7591">dynamic client registration</a> <cite title="NONE">[RFC7591]</cite> and <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html#UMA.RSR">dynamic resource set registration</a> <cite title="NONE">[UMA.RSR]</cite>."<br><br>As discussed on the UMA calls, the HEART profiles require dynamic registration of everything from the perspective of the Resource Server. We said: the resource server can issue "black box" warnings to the Resource Owner but cannot block dynamic registration of the specified Authorization Server. This MUST is essential to the HEART Delegation Use-Case and the control of resources under HIPAA patient right of access. <br><br></div>Dynamic registration also applies to Clients. Clients dynamically register with the Authorization Server and then present their token to the Resource Server. Any "black box" warnings regarding the particular Client would be issued by the Authorization Server.<br clear="all"><div><div><br></div><div>In section 3.2. Dynamic Registration of <a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html">http://openid.bitbucket.org/HEART/openid-heart-oauth2.html</a><br><p id="rfc.section.3.2.p.1">"Authorization servers MUST support dynamic client registration, and clients MAY register using the <a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7591">Dynamic Client Registration Protocol</a> <cite title="NONE">[RFC7591]</cite>
 for authorization code or implicit grant types. Clients MUST NOT 
dynamically register for the client credentials grant type. 
<b>Authorization servers MAY limit the scopes available to dynamically 
registered clients." </b>(my emphasis)<b><br></b></p><p>Is it clear in <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html">http://openid.bitbucket.org/HEART/openid-heart-uma.html</a> 
that the RS MUST honor the Client as authorized by the AS even if the RS
 does not have the opportunity to put up a warning during Phase 2 of the
 UMA sequence? <br></p><p>Can we be clearer in the HEART profiles on what the resource server MUST or SHOULD do when presented with a token from a Client they have not seen before?</p><p>Adrian<br></p></div><div><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</div></div></div>