<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 3, 2015, at 1:11 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class="">Inline...<br class=""><div class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Dec 3, 2015 at 9:14 AM, Justin Richer <span dir="ltr" class=""><<a href="mailto:jricher@mit.edu" target="_blank" class="">jricher@mit.edu</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
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 class=""></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" class="">
<br class="">
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 class=""></div></blockquote><div class=""><br class=""></div><div class="">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 class=""></div></div></div></div></div></div></div></blockquote><div><br class=""></div><div>User delegated means an end user delegates access and is involved in the process. Non-delegated means the client is acting on its own behalf for that step. This text is saying the RO needs to set up the relationship between the RS and the AS, but the RqP doesn’t have to be present on the wire to set up the relationship between the client and AS. This is to patch around a technical limitation in UMA 1.0 that would otherwise require the RqP have an account of some type at the AS that was able to generate OAuth tokens. </div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
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 class=""></div></blockquote><div class=""><br class=""></div><div class="">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 class=""></div><div class=""><br class=""></div><div class="">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.”</div></div></div></div></div></div></div></blockquote><div><br class=""></div><div>There are no data encryption keys, so this doesn’t make any sense. The resources will require separate tokens and the clients have separate keys for authentication. This isn’t data encryption though — we’re not talking about direct and SMIME here. You’re confusing the technologies with each other.</div><div><br class=""></div><div> — Justin</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Thanks,<br class=""><br class=""></div><div class="">Adrian<br class=""></div><div class=""><br class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="">
<br class="">
Thanks,<br class="">
-- Justin<div class=""><div class=""><br class="">
<br class="">
<div class="">On 12/3/2015 4:35 AM, Adrian Gropper
wrote:<br class="">
</div>
</div></div><blockquote type="cite" class=""><div class=""><div class="">
<div dir="ltr" class="">
<div class="">In section 4.1 Discovery of <a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html" target="_blank" class="">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" class="">JWK
Set</a> <cite title="NONE" class="">[RFC7517]</cite> format
) This is good and clear.<br class="">
<br class="">
</div>
<div class="">Correspondingly, in the UMA profile <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank" class=""></a><a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank" class="">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 class="">
<br class="">
</div>
<div class="">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 class="">
<br class="">
</div>
<div class="">Adrian<br class="">
</div>
<div class="">
<div class=""><br class="">
-- <br class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div class=""><br class="">
<div dir="ltr" class="">Adrian Gropper MD<span style="font-size:11pt" class=""></span><br class="">
<br class="">
<span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class="">PROTECT
YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""><br class="">
HELP us fight for the right to control
personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""><br class="">
DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><span style="color:rgb(5,99,193)" class="">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)" class=""></span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br class="">
<fieldset class=""></fieldset>
<br class="">
</div></div><pre class="">_______________________________________________
Openid-specs-heart mailing list
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank" class="">Openid-specs-heart@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br class="">
</div>
</blockquote></div><br class=""><br clear="all" class=""><br class="">-- <br class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><div dir="ltr" class="">Adrian Gropper MD<span style="font-size:11pt" class=""></span><br class=""><br class=""><span style="font-family:"Arial",sans-serif;color:#1f497d" class="">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""><br class="">HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""></span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""><br class="">DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><span style="color:#0563c1" class="">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d" class=""></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div>
</div></blockquote></div><br class=""></body></html>