<div dir="ltr"><div><div>HEART 2018-02-26</div><div><br></div><div>Attending:</div><div><br></div><div>Eve Maler</div><div>Adrian Gropper</div><div>Celestin Bitjonck</div><div>Justin Richer</div><div>Nancy Lush</div><div><br></div><div>Justin has reorganized our BitBucket page (<a href="https://openid.bitbucket.io/HEART/">https://openid.bitbucket.io/HEART/</a>), linked from our home page (<a href="http://openid.net/wg/heart/">http://openid.net/wg/heart/</a>), to be clearer about our document drafts. There’s a nice table there now. The Working Group Drafts column is all live-rendered.</div><div><br></div><div>The latest changes are in two categories. The OAuth2 spec changes are mostly to the FHIR (semantic) spec. The UMA spec “changes” are to both specs, to reflect UMA 2.0 updates. (Be sure to review the diffs carefully, especially if you’re an implementer; notes are not 100% complete.)</div><div><br></div><div>In the OAuth2 semantic spec, “aud” no longer points to a specific patient record. But the client can point to a specific resource if it has it. We may want to add some health warnings about checking RS against resource etc.</div><div><br></div><div>In the OAuth2 mechanical spec, the Client Types section got moved to be its own main section, and there are a few changes within that section. The subsection on Native Clients still requires the authorization code flow. Both confidential and public native clients are now allowed; each requires a unique public key, gotten through dynamic reg.</div><div><br></div><div>Read the new section for new PKCE details; native clients require it in many more circumstances.</div><div><br></div><div>Web server clients are not allowed to be public clients.</div><div><br></div><div>Do we agree with using “aud” as the more generic term the way SMART does? SMART hands over a selector and launch context. It’s a way for a client app to signal to the AS that it knows where to get to. When not a specific patient record, it’s a starting point. The next step is “Go talk to the AS.” and it’s up to the AS after that.</div><div><br></div><div>What is the relationship of our work to SMART? Not to change SMART, but to align our work with SMART where possible. SMART is working at being able to be plugged in today, and HEART is a little more about what’s possible. Those two things are starting to grow together.</div><div><br></div><div>What about the question of centrally managing consent, as TEFCA (for one) has asked? The HEART group is propounding a particular solution it thinks is straightforward, involving UMA.</div><div><br></div><div>The new UMA 2.0 specs started out with the UMA 1.0 spec text. They didn’t need a lot of changes. Most of the requirements are inherited from the OAuth2 specs. Most of the changes relate to handling tokens.</div><div><br></div><div>Constructs removed in UMA 2.0 were removed here (chiefly the AAT). New constructs are mentioned and handled (chiefly the PCT); the PCT is not required, though. The resource model hasn’t really changed; though the syntax has changed a lot from 1 to 2, we don’t need to mention it.</div><div><br></div><div>The deltas are so small between the UMA1 and UMA2 versions of the profiles that Justin essays possibly merging them somehow, if we want them both to be extant. That’s still a live topic. An exhaustive list of UMA1-to-UMA2 changes can be found at the UMA Release Notes (<a href="https://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes">https://kantarainitiative.org/confluence/display/uma/UMA+Release+Notes</a>).</div><div><br></div><div>Regarding breakfast: Eve will make a reservation for 12 at the recommended restaurant closest to her talk location and send notice to the list.</div><div><br></div></div><div>(Partial meeting recording is here: <a href="https://drive.google.com/file/d/17HYsReH2NHIazh3B-Aim-mGtKmH9jks4/view?usp=sharing">https://drive.google.com/file/d/17HYsReH2NHIazh3B-Aim-mGtKmH9jks4/view?usp=sharing</a> )</div><div><br></div><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">
<table border="0" cellspacing="0" cellpadding="0" style="font-family:Times"><tbody><tr><td valign="top"><a href="https://www.forgerock.com/" target="_blank"><img src="https://www.forgerock.com/img/ForgeRock_retina_email_bw_logo.png" width="185" height="70" border="0" alt="ForgeRock"></a></td><td valign="top" align="left" bgcolor="#ffffff" style="font-family:arial,helvetica,verdana,sans-serif;font-size:12px;color:rgb(47,52,56);line-height:19.8px"><strong>Eve Maler</strong><br>VP Innovation & Emerging Technology | ForgeRock<br><span style="color:rgb(249,76,35)"><strong>t</strong></span> (425) 345-6756 | <span style="display:inline-block"><span style="color:rgb(249,76,35)"><strong>e</strong></span> <a href="mailto:firstname.lastname@forgerock.com" style="color:rgb(47,52,56)" target="_blank">eve.maler@forgerock.com</a></span><br><span style="color:rgb(249,76,35)"><strong>twitter</strong></span> xmlgrrl | <span style="display:inline-block"><span style="color:rgb(249,76,35)"><strong>web</strong></span> <a href="https://www.forgerock.com/" style="color:rgb(47,52,56)" target="_blank">www.forgerock.com</a></span></td></tr></tbody></table></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>