<div dir="ltr">Indeed this is an opportunity for HEART, as a "sectoral" profile, to provide just such guidance. There are actually some technical ways to bridge a gap in access token validity (such as a "rolling" refresh pattern), if we wish to consider/mention them. Beyond that, we could consider the impacts at legal agreement levels (what's required if access fails at a critical juncture for certain kinds of data?) and even UX and extension spec levels if we see fit (asynchronous patient notifications?).</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"><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>London and Paris!</b></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Aug 29, 2016 at 11:14 PM, Thomas Rieneck <span dir="ltr"><<a href="mailto:THRE@sundhedsdata.dk" target="_blank">THRE@sundhedsdata.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="DA" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Well, to me it seems odd to omit clear operational guidance on how to handle the situation where the patient as Resource
Owner doesn’t have a valid PAT and is not available for reauthorization.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If some measure is needed here to circumvent proper authorization what is then left of the patients control of his or
her data?<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thomas Rieneck<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Fra:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Eve Maler [mailto:<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.<wbr>com</a>]
<br>
<b>Sendt:</b> 29. august 2016 20:57<br>
<b>Til:</b> Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>><br>
<b>Cc:</b> Thomas Rieneck <<a href="mailto:THRE@sundhedsdata.dk" target="_blank">THRE@sundhedsdata.dk</a>>; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.<wbr>openid.net</a><br>
<b>Emne:</b> Re: [Openid-specs-heart] Health Relationship Trust Profile for User Managed Access 1.0<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">In my personal experience, for whatever that's worth, even banks seem to have given up on everytime/daily required logins through mobile. It's possible to leverage a lot more silent contextual authentication cues of various sorts in more
clever fashion now -- deep device fingerprinting, geofencing, etc. (This is why I think merely counting factors is getting more and more useless, particularly as the "out-of-band-ness" of some of the factors should be questioned.)<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Can we truly attach concise and effective guidance to a SHOULD when the authentication picture is so complex and changeable, or should we really provide a SHOULD at all here, vs. the guidance alone?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">And keep in mind that a PAT is a special case of an OAuth access token, since it's designed to be used by the UMA resource server in some "resource owner is offline"
<a href="http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guide?src=contextnavchildmode#UMAImplementer'sGuide-RO-offlineEnsuringAsynchronousResourceServerAccesstoanAuthorizationServer" target="_blank">
circumstances</a>: a) for resource set registration that's potentially asynchronous to when the resource owner does something (say, the API just got a new version) and b) at client-driven access attempt time, when the resource owner isn't around unless they
also happen to be the requesting party. So needing to refresh it daily for <i>everyone else</i> to be able to use it when you're not around might be a big bummer.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The advice of the UMA Implementer's Guide, linked above, is: "The authorization server thus needs to manage the issuance and expiration of the PAT and and [sic] any corresponding refresh token appropriately to ensure that the resource server
has access when it needs it."<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p><b>Eve Maler<br>
</b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>
Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>
<b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">
are coming to</a> <b>London and Paris!</b><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Sat, Aug 27, 2016 at 3:24 PM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal">This is a recommendation, not a requirement, but better guidance might be warranted. The current text errs on the side of failing closed.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> — Justin<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">On Aug 26, 2016, at 4:55 AM, Thomas Rieneck <<a href="mailto:THRE@sundhedsdata.dk" target="_blank">THRE@sundhedsdata.dk</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Token Lifetimes for refresh tokens for PAT should not exceed 24 hours according to the above spec – that implies that Resource Owners should authenticate every
day for Requesting Parties being able to access their resources. </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">If the patient is the Resource Owner that does not seem realistic.</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Best regards</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Thomas Rieneck</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Nationale Health Data Agency</span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
</span><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954f72">Openid-specs-heart@lists.<wbr>openid.net</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954f72">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</span></a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>
</blockquote></div><br></div>