<div dir="ltr"><div>This is a subthread specific to the OIDC Certification issues in the 3 profiles currently up for discussion.<br><br></div>I'm trying to understand the HEART profile for OAuth 2.0 has numerous mentions of OpenID Connect including: <br><div><div style="margin-left:40px">"The authorization server MUST provide an 
OpenID Connect service discovery endpoint listing the components 
relevant to the OAuth protocol:"<br></div></div><div><div><div>as it relates to real-world implementations of an authorization server in the context of the HEART Use Cases.<br><br></div><div>The OpenID Certification page <a href="http://openid.net/certification/">http://openid.net/certification/</a> lists both Google and MITREid Connect. The key difference seems to be that OP Dynamic is not implemented by Google. <br><br></div><div>In the context of building a resource owner's authorization server like HIE of One, the AS wants to make it easy and clear as it decides to add trusted OPs to its OP whitelist. <br><br>Adding Google as an OP is certainly fussy. The steps involve access by the RO to a Credentials Page on their OP as detailed <a href="https://developers.google.com/identity/protocols/OpenIDConnect?hl=en">https://developers.google.com/identity/protocols/OpenIDConnect?hl=en</a> This is hardly a good user experience for a consumer that simply want to tell her authorization server to trust Google as a source of user authentication. <br><br></div><div>I presume that OPs that implement OP Dynamic such as MITREid Connect improve the fussy Google user experience. Let's consider a hospital called NPE (the resource server) that is willing to act as source of user authentication for access to their HEART-compliant API. <br>1 - Alice (RO) would start by logging in to the NPE (RS) patient portal<br></div><div>2 - Alice would provide the RS with something like a URI or an email address that enables the HEART-compliant RS to discover Alice's HEART-compliant AS (HIE of One).<br></div><div>3 - Alice's AS would put up some kind of authorization form listing NPE as a willing OP Dynamic identity provider for any provider that NPE is willing to take responsibility for authenticating.<br></div><div>4 - If Alice approves, this authorization form, then NPE is added to her AS whitelist of OPs.<br><br>If we're all together this far, we come up with some clarifying questions:<br><br></div><div>A - Why doesn't any well-known name on the OpenID Certified list implement OP Dynamic?<br><br></div><div>B - If HIE of One could get the Django help we need to implement OP Dynamic would the sequence 1-4 above be testable against <a href="http://healthauth.org">healthauth.org</a> with (alice/wonderland)?<br><br></div><div>C - When RSs implement the HEART profiles as currently proposed, will it be possible for Alice's AS to combine the authorization for NPE OP registration and NPE resource registration into a single form such as: <br><br><img alt="Inline image 1" src="cid:ii_1515e85908558fe7" height="446" width="545"><br>?<br><br></div><div>Adrian<br></div><div><br><br></div><div><br><br></div><div><br><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div>