<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Now that the HEART specs are Implementer’s Drafts, I wanted to provide some specific review comments about some of the ways that the current HEART specifications relate to general-purpose identity providers. The goal of these comments
is to increase their adoptability by parties running general-purpose identity providers, which will be good for HEART overall, while still maintaining HEART’s security and privacy goals.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There’s a number of things that the HEART specifications currently prohibit supporting that are required to be supported in the OpenID Basic Profile. This conflict means that general-purpose OPs can’t current support the HEART specs, which
isn’t in HEART’s best interest. I know, for instance, that Microsoft wouldn’t support them as currently written. We would use our general-purpose identity providers for healthcare applications – not separate identity providers set up for only that purpose.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">An example of such a conflict is that the Basic profile requires supporting client_secret_basic client authentication, whereas the HEART OAuth Profile prohibits its use. This means, for instance, that none of the 20 identity providers
that have been certified to the Basic profile at <a href="http://openid.net/certification/">
http://openid.net/certification/</a> could be HEART identity providers, even if they support the other functionality required by HEART, such as private_key_jwt client authentication.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This and things like it unnecessarily adversely affect the adoptability of the HEART specifications. Fortunately, there’s a simple solution to the problem. The way out of this is to write the profiles in such a way that servers can be
both general-purpose OPs and support HEART applications, whereas HEART clients can be restricted to only using HEART-specified mechanisms, such as private_key_jwt authentication. Existing servers could be extended to support both Basic and HEART functionality
– so that they can both be general-purpose servers and HEART servers. HEART clients can restrict themselves to using only the HEART-specified functionality such as private_key_jwt – maintaining HEART’s security and privacy goals.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I hope that the working group can agree to this principle as a basis for moving forward: HEART can require that OPs support additional functionality beyond that required for general-purpose OPs, but will not require removing any. HEART
clients must use only HEART-specified functionality, even if other functionality is available.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you for considering this feedback, which is intended to help make HEART more successful.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> -- Mike<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">P.S. I’ll send detailed feedback on specific HEART specification features in a separate message, which I’ll plan to get out in the next 24 hours.<o:p></o:p></p>
</div>
</body>
</html>