<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 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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><span style='color:#1F497D'>I support this. I had no idea that the HEART specs had conflicting requirements. The advantages of using general-purpose OPs is huge.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Are the differences being driven by perceived risk? If so, then we could certainly document the “Security Considerations” of the various realistic options. That is to be clear about the risks, rather than just forbidding something.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>John<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Openid-specs-heart [mailto:openid-specs-heart-bounces@lists.openid.net] <b>On Behalf Of </b>Mike Jones<br><b>Sent:</b> Monday, February 29, 2016 6:30 PM<br><b>To:</b> openid-specs-heart@lists.openid.net<br><b>Cc:</b> Anthony Nadalin<br><b>Subject:</b> [Openid-specs-heart] HEART specifications and their interactions with general-purpose identity providers<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><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="https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_certification_&d=CwMFAg&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=44sr67wvOOdr3YwMx-ygTAgcEoMedGgza7iOSHpx-_Q&s=5Pbz5S7kpEPHd-tKDbfuuNwWC83MtRk9hKE-NumwqkM&e=">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>