<div dir="ltr">Inline...<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 9:14 AM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
Your three points below aren't related to each other --
specifically, the middle one about resource registration isn't
related to key publication, at all. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
To the middle point: We state that the AS needs to support dynamic
resource registration (and client registration, which is a
prerequisite) and must allow the issuance of the corresponding PAT
through a normal OAuth flow (as opposed to the magical "you get a
token somehow we don't care" method in Core UMA). Such OAuth
behavior is already profiled in the OAuth profile which profiles
OAuth. If you think this can be clearer, please submit text making
it so.<br></div></blockquote><div><br></div><div>I will be happy to submit text for UMA Section 2 once I understand what user-delegated and non-delegated means and what the impact of RECOMMENDED vs. MUST will be in the context of resource registration. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
To the first and third points: It's stated in the OAuth profile that
the AS's JWK Set must be able to be fetched over HTTPS and may be
cached. It's up to the other side to do the fetching and caching,
including any RS that needs to register sets. I don't believe that
needs to be spelled out separately, but if you think it does, please
submit text.<br></div></blockquote><div><br></div><div>The most common objection by resource servers to dynamic registration of _any_ resource-owner-specified authorization server is that it is insecure to allow unverified clients to access the API that the resource server is responsible for. To mitigate this risk while also supporting the patient right of access requires access to separate security keys for each resource. (I think of this as "encryption at rest" applied to the API instead of the resource itself.) For this reason, I propose: <br></div><div><br></div><div>At the beginning or end of Section 4.1 Discovery, add: "The resource server MUST allow for each protected resource to be associated with a different authorization server public key as negotiated for issuance of the PAT."<br><br></div><div>Thanks,<br><br></div><div>Adrian<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
Thanks,<br>
-- Justin<div><div><br>
<br>
<div>On 12/3/2015 4:35 AM, Adrian Gropper
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div>
<div dir="ltr">
<div>In section 4.1 Discovery of <a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html" target="_blank">http://openid.bitbucket.org/HEART/openid-heart-oauth2.html</a>,
we have the requirement for each AS to have a public key (
jwks_uri The fully qualified URI of the server's public key in
<a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7517" target="_blank">JWK
Set</a> <cite title="NONE">[RFC7517]</cite> format
) This is good and clear.<br>
<br>
</div>
<div>Correspondingly, in the UMA profile <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank"></a><a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank">http://openid.bitbucket.org/HEART/openid-heart-uma.html</a>
I might expect a clearer reference to the resource
registration aspects of UMA. As far as I can tell, this is
mentioned in Section 2. Tokens as "It is RECOMMENDED that the
PAT use a user-delegated mechanism for issuance and the AAT
use a non-delegated method for issuance."<br>
<br>
</div>
<div>Does the HEART UMA profile require that a Resource Server
MUST be capable of storing a separate AS public key
(presumably the jwks_uri in OAuth 4.1) for every registered
resource? If so, where is this stated and could it be made
clearer?<br>
<br>
</div>
<div>Adrian<br>
</div>
<div>
<div><br>
-- <br>
<div>
<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>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
Openid-specs-heart mailing list
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><br>-- <br><div><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:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div>