<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Dynamic client registration is something that Google is looking for. How ever like HEART that probably won’t be any unknown OAuth Client without user or administrative consent.<div class=""><br class=""></div><div class="">At the moment the process for identifying a administrator and gather ing contact info is via a web portal and verified developer account. </div><div class=""><br class=""></div><div class="">Things may change over time to use 3rd party verification (Software statements) or some other mechanism. I would not hold my breath though.</div><div class=""><br class=""></div><div class="">At the moment personal authorization servers /data stores are still quite hypothetical from a real world deployment perspective, so things are still geared towards developers registering rather than users.</div><div class=""><br class=""></div><div class="">If the use case pans out then they will see pressure to support it.</div><div class=""><br class=""></div><div class="">I should not that Google was FICAM certified. However FICAM eliminated the LoA 1 certifications so it might be stretching it to say that they are certified by FICAM (That expired and there is no way to renew.)</div><div class=""><br class=""></div><div class="">At the moment the FICAM situation is that agencies using LoA 1 credentials are on there own hook to determine if they are suitable.</div><div class=""><br class=""></div><div class="">I point this out so that people don’t overly fixate on Google. Paypal and others were certified but that was for openID 2.</div><div class=""><br class=""></div><div class="">John B.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Dec 1, 2015, at 2:25 PM, Justin Richer <<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">On Dec 1, 2015, at 12:11 PM, Adrian Gropper <</span><a href="mailto:agropper@healthurl.com" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">agropper@healthurl.com</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">> wrote:</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">This is a subthread specific to the OIDC Certification issues in the 3 profiles currently up for discussion.<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">OIDC certification has nothing to do with HEART compliance, except that possible future HEART certification systems will follow that model. We’re not requiring compliance with OIDC Certification, especially not for the Oauth2 profile.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div>I'm trying to understand the HEART profile for OAuth 2.0 has numerous mentions of OpenID Connect including:<span class="Apple-converted-space"> </span><br class=""><div class=""><div class="" style="margin-left: 40px;">"The authorization server MUST provide an OpenID Connect service discovery endpoint listing the components relevant to the OAuth protocol:"<br class=""></div></div><div class=""><div class=""><div class="">as it relates to real-world implementations of an authorization server in the context of the HEART Use Cases.<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Again, I ask you to point out the “numerous mentions” and why those are problems as I’ve already explained why we’re using the discovery service from OIDC.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">The OpenID Certification page<span class="Apple-converted-space"> </span><a href="http://openid.net/certification/" class="">http://openid.net/certification/</a><span class="Apple-converted-space"> </span>lists both Google and MITREid Connect. The key difference seems to be that OP Dynamic is not implemented by Google.<span class="Apple-converted-space"> </span><br class=""><br class=""></div><div class="">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.<span class="Apple-converted-space"> </span><br class=""><br class="">Adding Google as an OP is certainly fussy. The steps involve access by the RO to a Credentials Page on their OP as detailed<span class="Apple-converted-space"> </span><a href="https://developers.google.com/identity/protocols/OpenIDConnect?hl=en" class="">https://developers.google.com/identity/protocols/OpenIDConnect?hl=en</a><span class="Apple-converted-space"> </span>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.<span class="Apple-converted-space"> </span><br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Agreed, but that’s something to bug Google about. It also means that you’ll be shipping your client credentials around with each copy of “HIE Of One” if you don’t want the individual copies to re-register by hand. </div><div class=""><br class=""></div><div class="">Furthermore, Google doesn’t support the private_key_jwt method required by HEART at the moment anyway, so it’s a bit of a moot point.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">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.<span class="Apple-converted-space"> </span><br class="">1 - Alice (RO) would start by logging in to the NPE (RS) patient portal<br class=""></div><div class="">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 class=""></div><div class="">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 class=""></div><div class="">4 - If Alice approves, this authorization form, then NPE is added to her AS whitelist of OPs.<br class=""><br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">That would work, but I don’t think it’s a full information flow. I know you’re not trying to show details here but I think that’s going to be required for this proposed system to be real. Best way to do that? Build it and run it! Also, it doesn’t mean that it’s whitelisted, it just means that it’s usable after being discovered and registered. This can all be done alongside statically registered systems, too. A whitelist means that users aren’t prompted for decisions, but if someone else on Alice’s OP logs in, you’d want to prompt them.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">If we're all together this far, we come up with some clarifying questions:</div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">A - Why doesn't any well-known name on the OpenID Certified list implement OP Dynamic?<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">They have a belief that they don’t have to: all the RPs will come to them and they can control the dynamic. There are spurious justifications for this at most providers.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">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<span class="Apple-converted-space"> </span><a href="http://healthauth.org/" class="">healthauth.org</a><span class="Apple-converted-space"> </span>with (alice/wonderland)?<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Probably.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">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: </div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""><span id="cid:ii_1515e85908558fe7" class=""><image.png></span><br class="">?<br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">The short answer is yes. You’re conflating the form and the functionality that it provides. One form can trigger many things with the right server. </div><div class=""><br class=""></div><div class=""> — Justin</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Adrian<br class=""></div><div class=""><br class=""><br class=""></div><div class=""><br class=""><br class=""></div><div class=""><br class=""><br class="">--<span class="Apple-converted-space"> </span><br class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><div dir="ltr" class="">Adrian Gropper MD<span class="" style="font-size: 11pt;"></span><br class=""><br class=""><span class="" style="font-family: Arial, sans-serif; color: rgb(31, 73, 125);">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span class="" style="font-family: Arial, sans-serif; color: rgb(31, 73, 125);"><br class="">HELP us fight for the right to control personal health data.</span><span class="" style="font-family: Arial, sans-serif; color: rgb(31, 73, 125);"></span><span class="" style="font-family: Arial, sans-serif; color: rgb(31, 73, 125);"><br class="">DONATE:<span class="Apple-converted-space"> </span><a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><span class="" style="color: rgb(5, 99, 193);">http://patientprivacyrights.org/donate-2/</span></a></span><span class="" style="color: rgb(31, 73, 125);"></span></div></div></div></div></div></div></div></div></div></div></div></div>_______________________________________________<br class="">Openid-specs-heart mailing list<br class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br class=""></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Openid-specs-heart mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:Openid-specs-heart@lists.openid.net" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Openid-specs-heart@lists.openid.net</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></div></blockquote></div><br class=""></div></body></html>