<div dir="ltr"><div dir="ltr"><div>Hi everyone-- Looking forward to our call on Monday; it's been a little while. The agenda for this meeting is:</div><div><br></div><div><i>Discussion whether a highly-secure health related profile(s) that aligns with the Financial Grade API (FAPI) would be beneficial to profile within HEART</i><br></div><div><br></div><div>The idea is that we may be able to learn and apply lessons from one or more of the FAPI security profiles (equivalent to what have called "mechanical" HEART profiles -- that is, not focusing on any financial-industry open API particulars of adding security/identity/privacy, but just on generic aspects of security and interop). Originally they were developed for specific application to the financial industry ("Financial API"), but ultimately it was felt these patterns are more broadly applicable, and the acronym was retrofitted to stand for "Financial-<b>Grade</b> API".</div><div><br></div><div>The <a href="https://openid.net/wg/fapi/">FAPI WG site</a> links to the latest specs. The two to examine for now are "<a href="http://openid.net/specs/openid-financial-api-part-1.html">FAPI Part 1: Read Only API Security Profile</a>" and "<a href="http://openid.net/specs/openid-financial-api-part-2.html">FAPI Part 2: Read & Write API Security Profile</a>". Both recently reached implementer's draft stage. (Our latest specs are <a href="https://openid.bitbucket.io/HEART/">here</a> -- there seems to be an issue with rendering at the moment that I hope we can sort out shortly.)</div><div><br></div><div>Some items to think about:</div><div><ul><li>FAPI merges OAuth and OpenID Connect profiling together. We have done that in separate specs by turn (with a third for UMA).</li><li>FAPI profiles two levels of security, where "read" operations are lower-sensitivity and "read & write" is higher-sensitivity. We don't have any such clean lines (what might be called "named security modes").</li><li>FAPI's writing style is to provide numbered list-item clauses, to aid testability and reference. Our style is more prose-oriented.</li><li>FAPI's design center is security in a financial services context first and foremost, despite the broadened name. Of the requirements and guidelines in these profiles, how do they and the HEART equivalents actually compare, and do any of the actual profiling outcomes turn out to align well enough to inspire/teach/directly influence any of our own work, and/or vice versa?</li></ul></div><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><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:eve.maler@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></div></div></div>