<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="">No doubt the the OpenID Connect certification process is exemplary and has helped drive adoption and interoperability, and in fact we’re developing a similar tool suite for HEART as well. HEART has a wider mission than just OIDC, of course, and so we need to consider specifying functionality that is more easily left to the implementors in OIDC. <div class=""><br class=""></div><div class="">Unlike most members of the list, I was present during the decision to drop the CheckID endpoint, as evidenced by the issue I filed at the time to track the token introspection draft: <a href="https://bitbucket.org/openid/connect/issues/581/general-token-introspection" class="">https://bitbucket.org/openid/connect/issues/581/general-token-introspection</a> (which was marked resolved without action by the editors). The CheckID endpoint in Connect was redundant, and I believe that *that* rationale is perfectly sound today as it was then. However, it was never an issue of giving *more* information or *different* information, it was a matter of the server unpacking *exactly* what was already in the JWT. The rationale for the endpoint was that it would save a client developer from using a JWT library at all, even to parse. If you read the current draft specs, that is not at all the intent in HEART. The information inside the JWT and inside the introspection response is intended to be distinct, and to fit different purposes. This is based on deployment experience and developer feedback over several projects, both what information is useful and what processes are able to be managed.</div><div class=""><br class=""></div><div class="">The thing is, we’re talking about very different kinds of situations here. The ID Token in connect is an assertion that is received directly by the party which is intended to consume it and isn’t handled by any third parties. Ergo, it needn’t be encrypted in the usual case in order to protect its contents: the client is the only party that handles the ID Token, it can read it directly. Additionally, the ID Token is intended to be consumed and effectively discarded. As it represents the authentication event, and never is passed to another system for access, the client can parse it and go on its way. The access token is a different beast entirely: it is received directly by the client and then handed to the protected resource. The client therefore has access to the token’s contents on the wire, and therefore potentially privacy-leaking information like “sub” and “scope” need to be protected from the prying eyes of the client. Indeed, even the audience list for the access token could be privacy leaking by allowing one resource server to discover, by way of an access token, that the user represented by one of its own records is also represented by a particular record on another server. By using an online lookup mechanism, introspection, we can very effectively limit the information inside the token to that which is needed for an optional first pass discovery and validation, and move all privacy sensitive information to the introspection response, which can of course be tailored to the protected resource that’s requesting it. </div><div class=""><br class=""></div><div class="">Additionally, as long as a JWT is within its specified time period, it’s considered valid. If you’re using entirely stateless tokens, you can’t revoke them once they’ve been minted. This is simply not acceptable in many transactions in the healthcare (and other) domains, where fast revocation is a requirement for security. History has shown us that any standalone system, like X509 certificates for example, end up requiring a live status check mechanism in some circumstances, like OCSP for X509 certs. This is to say nothing of the growing size requirements for putting more and more information in the token itself. Many of us have seen how SAML assertions and their ilk have a tendency to explode overtime as new requirements and claims get brought into the mix. After all, a self-contained token needs to be ready to answer any question that might possibly be asked of it by any party down the line. This leads to bloat and confusion. </div><div class=""><br class=""></div><div class="">I am aware, though many in the list might not be, that this is in contrast to capabilities available in Microsoft’s current product offering. Microsoft’s server currently issues encrypted JWTs that are keyed to the individual protected resource. This would solve the privacy issue mentioned above (though not liveness), so why doesn’t HEART just adopt encrypted access tokens? This of course requires registration and management of keys for protected resources, something that hasn’t been discussed here. It also historically is the source of Microsoft’s previously-required “resource” parameter to indicate the resource server and allow the AS to choose the correct key to encrypt the token with. This approach broke interoperability with off-the-shelf OAuth libraries and had to be worked around, as I understand it, for the OpenID Connect implementation to pass certification. Since HEART’s goals are beyond just OpenID Connect interoperability, we need to consider the impact of such decisions across AS and RS implementations from multiple vendors. </div><div class=""><br class=""></div><div class="">In the end, we chose to balance between JWT and Introspection and specify both be made available to satisfy HEART’s goals. I agree that the justifications for this and other points below need to be spelled out better, but I do not agree with your conclusions regarding the appropriateness of introspection within the specification. Yes, we realize that some vendors will either need to implement this as new functionality or decide that they will not be a HEART compliant AS. That’s the same as with JWT formatted tokens with other vendors. You’ll note, of course, that neither of these requirements apply to HEART OIDC IdP’s, as is now stated in the current document drafts, thanks directly to your feedback. We anticipate that, much like the OIDC compliance tests, some vendors will decide to conform to some aspects of HEART’s profiles and not others, and we need to allow that in a way that isn’t detrimental to interoperability. </div><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 10, 2016, at 4:40 AM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" class="">Michael.Jones@microsoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255);"><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(0, 32, 96);" class="">Let me second and expand upon Glen’s point. OpenID Connect is designed to enable broad interoperability, with a strong certification program<span class="Apple-converted-space"> </span><a href="http://openid.net/certification/" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/certification/</a><span class="Apple-converted-space"> </span>as a tool to help practically promote that interoperability. If the HEART specifications begin unnecessarily requiring functionality not necessary to satisfy the HEART mission, it will necessarily limit the applicability of the HEART profiles. (Yes, some additional things are needed, but each addition should be clearly justified.)<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(0, 32, 96);" class="">Also, I’ll respond here to Justin’s comment “</span>Interestingly, you find JWT reasonable and introspection not reasonable, while others have had the opposite view.<span style="color: rgb(0, 32, 96);" class="">” The OpenID Connect working group explicitly decided to require that both OPs and RPs understand JWTs *<b class="">exactly</b>* so that they wouldn’t have to bear the additional implementation and run-time costs of introspection.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: rgb(0, 32, 96);" class="">Some people won’t remember this, but OpenID Connect used to have an introspection endpoint called the Check ID Endpoint, but based on developer feedback, it was removed in May 2012 (see<span class="Apple-converted-space"> </span><a href="https://bitbucket.org/openid/connect/issues/570" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">https://bitbucket.org/openid/connect/issues/570</a><span class="Apple-converted-space"> </span>and<a href="http://openid.net/specs/openid-connect-messages-1_0-10.html#anchor24" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-connect-messages-1_0-10.html#anchor24</a>).<a name="_MailEndCompose" class=""><span class="Apple-converted-space"> </span> Developers made it clear to us they would rather process JWTs directly, which they said based on experience, is easy, than pay the unnecessary costs of an introspection endpoint.<o:p class=""></o:p></a></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><span style="color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><span style="color: rgb(0, 32, 96);" class="">I believe that this rationale from developers is just as valid in 2016 as it was in 2012. Therefore, please likewise simplify and increase the interoperability of the HEART profiles by removing the requirement for introspection.<o:p class=""></o:p></span></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><span style="color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><span style="color: rgb(0, 32, 96);" class=""> -- Mike<o:p class=""></o:p></span></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><span style="color: rgb(0, 32, 96);" class=""><o:p class=""> </o:p></span></span></div><span class=""></span><div class=""><div style="border-style: solid none none; border-top-color: rgb(225, 225, 225); border-top-width: 1pt; padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="color: windowtext;" class="">From:</span></b><span style="color: windowtext;" class=""><span class="Apple-converted-space"> </span>Glen Marshall [SRS] [<a href="mailto:gfm@securityrs.com" class="">mailto:gfm@securityrs.com</a>]<span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Monday, May 9, 2016 11:52 AM<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span><a href="mailto:openid-specs-heart@lists.openid.net" class="">openid-specs-heart@lists.openid.net</a><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>Mike Jones <Michael.Jones@microsoft.com><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>RE: [Openid-specs-heart] Feedback on the HEART OAuth and OpenID Connect profiles from Mike Jones<o:p class=""></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; color: windowtext;" class="">Mike Jones is onto something that may create difficulties for HEART. In the cross-industry world, where healthcare is an equal partner with other industries, how much interoperability is required? OAuth and UMA imply, at least to me, rather broad interoperability where one might have one place to express privacy requirements that apply to many different aspect of one’s life. I suspect that the current US-centric boundaries for what is and isn’t health IT are more porous and less worldwide that we might have assumed. <o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; color: windowtext;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; color: windowtext;" class="">I would like to see some traceability from business and policy requirements to the technical profiles. For example, is the assumption of having an indeterminate number of AS services with real-time discovery required by business or policy, or is an eventual goal. How much new infrastructure is needed, and who will bear the costs and responsibility for it?<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; color: windowtext;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; color: windowtext;" class=""><o:p class=""> </o:p></span></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class="">Glen F. Marshall<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class="">Consultant<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class="">Security Risk Solutions, Inc.<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class="">698 Fishermans Bend<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class="">Mount Pleasant, SC 29464<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class="">Tel: (610) 644-2452<span class="Apple-converted-space"> </span><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class="">Mobile: (610) 613-3084<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class=""><a href="mailto:gfm@securityrs.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">gfm@securityrs.com</a><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="color: windowtext;" class=""><a href="http://www.securityrisksolutions.com/" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">www.SecurityRiskSolutions.com</a><o:p class=""></o:p></span></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; color: windowtext;" class=""><o:p class=""> </o:p></span></div><div class=""><div style="border-style: solid none none; border-top-color: rgb(225, 225, 225); border-top-width: 1pt; padding: 3pt 0in 0in;" class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="color: windowtext;" class="">From:</span></b><span style="color: windowtext;" class=""><span class="Apple-converted-space"> </span>Openid-specs-heart [<a href="mailto:openid-specs-heart-bounces@lists.openid.net" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">mailto:openid-specs-heart-bounces@lists.openid.net</a>]<span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Justin Richer<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>Sunday, May 8, 2016 08:26<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Michael.Jones@microsoft.com</a>>;<span class="Apple-converted-space"> </span><a href="mailto:openid-specs-heart@lists.openid.net" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">openid-specs-heart@lists.openid.net</a><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [Openid-specs-heart] Feedback on the HEART OAuth and OpenID Connect profiles from Mike Jones<o:p class=""></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><p style="margin-right: 0in; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Hi Mike,<span style="font-size: 12pt;" class=""><o:p class=""></o:p></span></p><p style="margin-right: 0in; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thanks for the thorough review. It's clear to me that for the most part the specs lack the appropriate justification for the decisions made therein, something that we've started to address with the latest draft changes. I'll go through each point below in turn when I get a chance later this week, but for example: the requirement for introspection at the OAuth AS is to allow interoperable onboarding of RS's. Instead of leaving this as an implementation choice, we are mandating the availability of this connection mechanism for interop. If you've got an embedded RS with your AS, you don't need to use it, but you need to make it available from the AS in order to allow other RS's to connect to you. Note: this is not a requirement of a Connect IdP that's not also acting as an OAuth AS (this point has been clarified in the latest drafts that I linked to the list the other day, I'd ask that you take a look at the new text, please!). Interestingly, you find JWT reasonable and introspection not reasonable, while others have had the opposite view. Therefore we need to clearly state why we have both, as we've attempted to do in the current draft:<o:p class=""></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.4.2" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.4.2</a><o:p class=""></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class="">We realize that some of the decisions in the profiles are departures from what's common on OAuth systems, and that's OK. The goal of HEART is not to document what people are already doing, but instead to push the boundary of security and interoperability for this and possibly other vertical domains.<span class="Apple-converted-space"> </span><o:p class=""></o:p></p><p style="margin-right: 0in; margin-left: 0in; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> -- Justin<o:p class=""></o:p></p><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">On 5/8/2016 1:27 AM, Mike Jones wrote:<o:p class=""></o:p></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" 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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html</a></span></b><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.1</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">2.1.1.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#FullClient" id="FullClient" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Full Client with User Delegation</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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”?<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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”?<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.2</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">2.1.2.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#BrowserClient" id="BrowserClient" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Browser-embedded Client with User Delegation</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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”?<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.3</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">2.1.3.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#DirectClient" id="DirectClient" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Direct Access Client</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.2</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">2.2.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#RequestsToTokenEndpoint" id="RequestsToTokenEndpoint" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Requests to the Token Endpoint</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">JWA</a><span class="Apple-converted-space"> </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;" class="">http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms</a><span class="Apple-converted-space"> </span>– not the JWA spec.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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?<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">3.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#ClientRegistration" id="ClientRegistration" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Client Registration</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3.2</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">3.2.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#DynamicRegistration" id="DynamicRegistration" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Dynamic Registration</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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?<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.4" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">4.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#ServerProfile" id="ServerProfile" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">OAuth 2.0 Server Profile</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.4.1" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.1</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">4.1.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#Discovery" id="Discovery" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Discovery</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.4.2" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.2</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">4.2.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#JWTBearerTokens" id="JWTBearerTokens" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">JWT Bearer Tokens</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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?<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><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;" class="">https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and</a><span class="Apple-converted-space"> </span>-<span class="Apple-converted-space"> </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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.5</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">5.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#RequestsToProtectedResource" id="RequestsToProtectedResource" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Requests to the Protected Resource</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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”.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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="">OpenID Connect Profile -<span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html</a></span></b><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">2.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#IDTokens" id="IDTokens" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">ID Tokens</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.3" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.3</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">3.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#UserInfoEndpoint" id="UserInfoEndpoint" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">UserInfo Endpoint</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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;" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.4</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">4.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#RequestObjects" id="RequestObjects" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Request Objects</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.5" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.5</a><o:p class=""></o:p></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;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">5.</span></a><span class="Apple-converted-space"> </span><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#AuthenticationContext" id="AuthenticationContext" style="color: rgb(149, 79, 114); text-decoration: underline;" class=""><span style="color: rgb(51, 51, 51); text-decoration: none;" class="">Authentication Context</span></a></span><o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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.<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></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).<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><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).<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> Thanks all,<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> -- Mike]<o:p class=""></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><br class=""><br class=""><o:p class=""></o:p></span></p><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New', serif;" class="">_______________________________________________<o:p class=""></o:p></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New', serif;" class="">Openid-specs-heart mailing list<o:p class=""></o:p></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New', serif;" class=""><a href="mailto:Openid-specs-heart@lists.openid.net" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">Openid-specs-heart@lists.openid.net</a><o:p class=""></o:p></pre><pre style="margin: 0in 0in 0.0001pt; font-size: 10pt; font-family: 'Courier New', serif;" class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p class=""></o:p></pre></blockquote><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt; font-family: 'Times New Roman', serif;" class=""><o:p class=""> </o:p></span></div></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255); float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255);" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255); 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-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255);" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255); float: none; display: inline !important;" class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255);" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255); float: none; display: inline !important;" class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: 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; background-color: rgb(255, 255, 255);" class=""></div></blockquote></div><br class=""></div></body></html>