<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="">Software statements are defined in RFC7591:<div class=""><br class=""></div><div class=""><a href="https://tools.ietf.org/html/rfc7591#section-2.3" class="">https://tools.ietf.org/html/rfc7591#section-2.3</a></div><div class=""><br class=""></div><div class="">Essentially they lock down parts of a dynamic registration process by carrying client information with a trusted signature.</div><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 18, 2016, at 4:01 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">Thank you Mike and Justin!!! What is a software statement?<div class=""><br class=""></div><div class="">-Adrian<br class=""><br class="">On Wednesday, May 18, 2016, Justin Richer <<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi Mike,<div class=""><br class=""></div><div class="">Thanks again for the thorough review of the specifications. Comments and replies to each point are inline here. </div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On May 8, 2016, at 12:27 AM, Mike Jones <<a href="javascript:_e(%7B%7D,'cvml','Michael.Jones@microsoft.com');" target="_blank" class="">Michael.Jones@microsoft.com</a>> wrote:</div><br class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">The 27 review feedback items below are based upon a complete read of the HEART OAuth and OpenID Connect profiles during the Implementer’s Draft review follows. I believe that all the comments equally apply to the current working group drafts. I’ve used links to the Implementer’s Drafts below since these are stable references to immutable versions. They are intended to make the profiles clearer, more easily understood, more easily implemented, and more secure.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><b class=""><span style="font-size:14pt" class="">OAuth Profile -<span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html</a><u class=""></u><u class=""></u></span></b></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.1" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.1</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.1" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">2.1.1.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#FullClient" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Full Client with User Delegation</span></a><u class=""></u><u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(1) Why is this called a “full client”? Wouldn’t a more descriptive name be something more aligned with OAuth naming, like “Client using Authorization Code Flow” or with OpenID Connect naming, like “Basic Client”?</div></div></div></blockquote><div class=""><br class=""></div><div class="">The name here comes from the original SecureRESTFUL project at the VA that originally developed the specifications, and we haven’t gotten any other feedback to change the names. Instead of naming it after the flow, we want it to reflect the nature of the client itself. Perhaps “User Interactive Client”?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(2) Especially in light of the OAuth mix-up attacks, wouldn’t it be better for these clients to use, or at least be allowed to use, “response_type=id_token code”, rather than be required to use “response_type=code”?</div></div></div></blockquote><div class=""><br class=""></div><div class="">This is still a controversial approach in the OAuth WG, so I don’t think we should jump in and advocate support for it here. Since the delivery method for “id_token code” and “code” are completely different, I believe that it hurts interoperability to allow both for this profile. I would suggest a new profile to support the other methods. If “id_token code” were delivered in the same manner as “code”, that would be a different story, as the addition of the id_token would require very little change to the client application. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(3) What is the “unique key” that is RECOMMENDED used for, how is it used, and what restrictions are there on the key type? For instance, is it assumed to be an asymmetric key? Are there required or recommended algorithms to use, such as “RS256”? The spec should say more about this in the interests of both interoperability and clarity.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Thanks, this could be clearer. We intended this to be an asymmetric keypair generated on the device, with RS256 as the baseline for support. It also needs to be registered in JWK format, which is specified elsewhere but can be restated here.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(4) What are the implications of not having the “unique key” (not following the RECOMMENDED)? Why is this RECOMMENDED, rather than REQUIRED? For one thing, not having this key would seem to conflict with the requirement in 2.2 to use private_key_jwt client authentication.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The alternative is to have the key generated off-device and provisioned to it, not to have “no key” instead. This can be clarified, thanks!</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.2</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">2.1.2.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#BrowserClient" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Browser-embedded Client with User Delegation</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(5) Why is this called “Browser-embedded Client” when this flow could also be used by non-browser applications? Why not follow the OAuth and Connect naming conventions and call this an “Implicit Client”?</div></div></div></blockquote><div class=""><br class=""></div><div class="">It’s almost universally considered bad practice to use the implicit flow for anything but an in-browser client, and we very explicitly don’t want to encourage bad practices. Thus I think that “Browser-embedded Client” makes the most sense here.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.3" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.3</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.3" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">2.1.3.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#DirectClient" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Direct Access Client</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(6) What is the use case behind the decision for the profile to include use of the Client Credentials flow, especially when this bypasses user involvement and user consent? Is including this actually necessary? Many servers don’t support this, by design.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yes, we have use cases and drivers for this kind of access. Discussion is on the list archives for this.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.2</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">2.2.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#RequestsToTokenEndpoint" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Requests to the Token Endpoint</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(7) The text “<span lang="EN" style="font-size:10pt;font-family:Verdana,sans-serif" class="">MAY use other asymmetric signature methods listed in the JSON Web Algorithms (<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#RFC7518" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">JWA</a><span class=""> </span><cite style="font-style:normal" class="">[RFC7518]</cite>) specification</span>” should actually refer to the IANA JSON Web Signature and Encryption Algorithms registry at<a href="http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms</a>– not the JWA spec.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Good point, thanks. I’m not sure how to include a reference to an IANA registry in xml2rfc, but we’ll fix that.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(8) The paragraph including “<span lang="EN" style="font-size:10pt;font-family:Verdana,sans-serif" class="">Authorization servers MAY require some clients to additionally authenticate using mutual Transport Layer Security (TLS) authentication</span>” is problematic in several ways. First, how does the server communicate to the client that mutual TLS is required? How is the client TLS key registered with the server? Is support for mutual TLS required of servers? Of clients? If it’s not required, how is interop assured when it is used?<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is something that’s not very well baked. In the original environment for the SecureRESTFUL project, there was a customer requirement to allow for mutual TLS authentication, even if we weren’t specifying how it will happen. I agree that it doesn’t add to interoperability, so I suggest to the WG that we strike this allowance and remain silent on it.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">3.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#ClientRegistration" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Client Registration</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(9) The profile requires that “<span lang="EN" style="font-size:10pt;font-family:Verdana,sans-serif" class="">each client instance MUST receive a unique client identifier from the authorization server</span>”. This isn’t how most OAuth deployments work today – particular for native applications. Is this significant departure from existing practice truly necessary or is this just a preference? If it’s necessary, the specification should clearly say why. If it’s not truly necessary, this requirement should be downgraded to being a recommendation.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">We don’t really have public clients in HEART, which is what usually causes a client ID to be re-used for native applications. We do require dynamic registration be made available to support this.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3.2</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">3.2.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#DynamicRegistration" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Dynamic Registration</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(10) The profile requires the use of Dynamic Registration. This is another significant departure from existing practice. Like the previous comment, this requirement either needs to be justified as being essential or downgraded to being a recommendation.</div></div></div></blockquote><div class=""><br class=""></div><div class="">See above. We want a brand new piece of HEART client software to be able to walk up to a HEART AS and register without going through a manual page. We realize it’s a significant departure and believe that it’s essential to HEART’s mission of wide interoperability and smooth integration.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(11) The profile indicates that servers MAY accept software statements. How does the server communicate to clients that it supports software statements or not? How does it communicate whether their use by clients is required or not? How does it communicate to developers and clients what kinds of software statements will be accepted and rejected?<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">This isn’t fully baked, either in HEART or in the wider community. Software statements are a great idea but under defined, and we need to decide in HEART whether we want to lock that down, leave an allowance for it, or remain silent.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(12) The profile requires that authorization servers “<span lang="EN" style="font-size:10pt;font-family:Verdana,sans-serif" class="">MUST indicate to the end user that such a statement was used in the client's registration</span>”. This seems beyond silly, as most normal people would have no clue what such a message means or how they should respond to it (or the lack of it). Requiring another “Click OK” barrier in the UI that people won’t understand and will just click through won’t help either usability or security.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">We need better guidance on the UX process. Really, we want to tell authorization servers that they should flag whether a client was:</div><div class=""> - dynamically registered</div><div class=""> - dynamically registered with a trusted software statement</div><div class=""> - statically registered through a self-service</div><div class=""> - statically registered by an administrator</div><div class=""><br class=""></div><div class="">These are all different trust classes for clients, and each is valuable in the HEART space. We welcome better text for this section, especially backed by empirical research as opposed to anecdotal experience (which is what we’re working with at the moment).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">4.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#ServerProfile" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">OAuth 2.0 Server Profile</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(13) The profile requires that “<span lang="EN" style="font-size:10pt;font-family:Verdana,sans-serif" class="">The authorization server MUST limit each registered client (identified by a client ID) to a single grant type only</span>”. This may or may not be fine but doesn’t match existing practice for many implementations and the requirement isn’t justified in the specification. At a minimum, clear rationale for this requirement needs to be included.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">This fits with the client profile definitions, and we can add better rationale for it. It’s largely security based.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.1" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.1</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.1" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">4.1.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#Discovery" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Discovery</span></a><u class=""></u><u class=""></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(14) The profile requires support for the introspection endpoint. This unnecessarily increases the implementation footprint of both clients and servers, increases run-time cost of common operations, and is a significant deviation from most deployments. If, for instance, the UMA profile requires introspection for some reason, add it there, but do not require HEART OAuth or Connect to support introspection. This must be removed from the OAuth profile.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Discussed in the other thread, this requirement will not be removed. Better justification can be provided.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(15) The profile requires support for the revocation endpoint. This unnecessarily increases the implementation footprint of both clients and servers and is a significant deviation from most deployments. If, for instance, the UMA profile requires revocation for some reason, add it there, but do not require HEART OAuth or Connect to support revocation. This must be removed from the OAuth profile.</div></div></div></blockquote><div class=""><br class=""></div><div class="">For reasons similar to the introspection endpoint, this function is made available to clients that want to behave proactively. Better justification can be supplied as well.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(16) The profile states “<span lang="EN" style="font-size:10pt;font-family:Verdana,sans-serif" class="">It is RECOMMENDED that servers provide cache information through HTTP headers and make the cache valid for at least one week.</span>” How does this interact with the need to immediately rotate keys upon key compromise? Is this saying that a compromised key must remain valid for at least a week? If this isn’t implied by this recommendation, please explain what is actually implied for clients and servers.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">We’re open to better cache guidance. Cache consistency is hard, since we don’t want clients and resources to fetch the AS key every single request (I’ve seen naive clients do just that), cache is a good idea. But if someone’s compromised the key, you’ll probably want some type of cache-busting signal, like what RISC is talking about for account compromise. </div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.2</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">4.2.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#JWTBearerTokens" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">JWT Bearer Tokens</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(17) The spec is unclear what kinds of bearer tokens are being referred to here. Is it saying that access tokens must be JWTs? Is it saying that refresh tokens must be JWTs? This is certainly a reasonable implementation choice but the specification does not clearly state why this is a requirement. Please say why bearer tokens must be JWTs.</div></div></div></blockquote><div class=""><br class=""></div><div class="">The draft specs do better at this but I’m sure this can be clearer. The JWT format was used to allow resources to have a first-order validity check against tokens without having to call introspection (which is still needed for token active status as well as privacy-sensitive data like user ID, scopes, etc). This also allows an RS to accept tokens issued by multiple RS’s, which has been raised as a desirable deployment mode for HEART systems.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(18) The profile says that an audience may be included. Why is the audience not required? What are the implications of sending and accepting bearer tokens that aren’t audience?<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">The problem is that it’s hard to specify audience in OAuth right now, so there’s a lot of friction in requiring its inclusion. We’re going to be specifying some audience components in the FHIR/OAuth spec, which would fit here. This relaxed restriction can be made clearer.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(19) The profile requires including “azp” in JWT bearer tokens. It’s now widely held by the OpenID Connect working group that “azp” is both underspecified and its inclusion in OpenID Connect was a mistake. (See<a href="https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and</a><span class=""> </span>-<span class=""> </span><span lang="EN" style="font-family:Arial,sans-serif" class="">Core 2 / 3.1.3.7 - azp claim underspecified and overreaching.</span>) Please remove all uses of “azp” from the HEART specifications. If the client ID needs to be conveyed, an appropriate new well-specified claim should be defined and used for this purpose.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Except that we’re defining the “azp” to *be* the client ID, so I don’t see a problem in using that field. We could easily just make it “client_id” to convey the information from the introspection endpoint.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.5" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.5</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.5" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">5.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#RequestsToProtectedResource" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Requests to the Protected Resource</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(20) The profile says that resources may support the query-parameter parameter method from RFC 6750. This is a terrible security mistake. Change the text to say that “Resources MUST NOT support the query-parameter parameter method from RFC 6750”.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">The security parameter has its use cases with appropriate caveats. I don’t see a reason to remove it.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><b class=""><span style="font-size:14pt" class="">OpenID Connect Profile -<span class=""> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html</a></span></b><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">2.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#IDTokens" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">ID Tokens</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(21) The profile says that “<span lang="EN" style="font-size:10pt;font-family:Verdana,sans-serif" class="">The ID Token MUST expire and SHOULD have an active lifetime no longer than five minutes</span>”. While this expiration time may be a reasonable implementation choice, the specification is silent on why this reasonably short expiration time is a requirement. Please either justify this requirement or downgrade this text to a non-normative discussion on criteria for choosing appropriate ID Token lifetimes.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">All the tokens have recommended lifetimes, just like this one. We can justify this easily — it’s an authentication event assertion, you use it once and chuck it. Five minutes is generous.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.3" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.3</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.3" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">3.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#UserInfoEndpoint" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">UserInfo Endpoint</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(22) The profile requires supporting signed UserInfo responses. This may be a reasonable thing for the profile to require but the specification fails to motivate this requirement. Please do so.</div></div></div></blockquote><div class=""><br class=""></div><div class="">It’s to allow for a higher-security mode, optional for the client. We can provide better justification.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(23) The profile talks about encrypted UserInfo responses but doesn’t say whether support for these is required for clients or servers, or why. Please do so.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Same as above. Plus, all HEART OIDC clients have keys registered, so encryption is generally possible here where it’s less tenable in the general OIDC case.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.4" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.4</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.4" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">4.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#RequestObjects" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Request Objects</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(24) The profile requires that servers support request objects. This may be a reasonable thing for the profile to require but the specification fails to motivate this requirement. Please do so.<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">Justification can be added: To support higher security modes optionally from the clients</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.5" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.5</a><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><span lang="EN" style="font-family:Verdana,sans-serif" class=""><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.5" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">5.</span></a><span class=""> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#AuthenticationContext" style="color:rgb(149,79,114);text-decoration:underline" target="_blank" class=""><span style="color:rgb(51,51,51);text-decoration:none" class="">Authentication Context</span></a></span><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(25) The profile uses URIs for FICAM LOA numbers as “acr” values. This seems short-signed and limiting, as these values are specific to the United States and not international in nature. These must be changed to appropriate international equivalents – especially in coordination with other working groups, such as MODRNA.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This part is known to be woefully incomplete. We want to provide implementations with a list here, but such a list doesn’t exist that I’m aware of.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(26) Remove the requirement to support the introspection endpoint from this profile, for the same reasons as in (14).<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is now no longer a requirement as per the new “conformance” section.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">(27) Remove the requirement to support the revocation endpoint from this profile, for the same reasons as in (15).</div></div></div></blockquote><div class=""><br class=""></div><div class="">Since this is how the client interacts with the AS, the requirement currently carries through, with the same justification.</div><div class=""><br class=""></div><div class=""> — Justin</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> Thanks all,<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""> -- Mike]<u class=""></u><u class=""></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing: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-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="javascript:_e(%7B%7D,'cvml','Openid-specs-heart@lists.openid.net');" style="color:rgb(149,79,114);text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">Openid-specs-heart@lists.openid.net</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" style="color:rgb(149,79,114);text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""><br class="">-- <br class=""><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 style="font-size:11pt" class=""></span><br class=""><br class=""><span style="font-family:"Arial",sans-serif;color:#1f497d" class="">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""><br class="">HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""></span><span style="font-family:"Arial",sans-serif;color:#1f497d" class=""><br class="">DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><span style="color:#0563c1" class="">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d" class=""></span>
</div></div></div></div></div></div></div><br class="">
</div></blockquote></div><br class=""></div></body></html>