<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
cite
{mso-style-priority:99;
font-style:normal;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt;color:windowtext">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></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:windowtext">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></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:windowtext"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="color:windowtext">Glen F. Marshall<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Consultant<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Security Risk Solutions, Inc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">698 Fishermans Bend<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Mount Pleasant, SC 29464<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Tel: (610) 644-2452 <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Mobile: (610) 613-3084<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">gfm@securityrs.com<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><a href="http://www.securityrisksolutions.com/"><span style="color:#0563C1">www.SecurityRiskSolutions.com</span></a><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span style="color:windowtext"> Openid-specs-heart [mailto:openid-specs-heart-bounces@lists.openid.net]
<b>On Behalf Of </b>Justin Richer<br>
<b>Sent:</b> Sunday, May 8, 2016 08:26<br>
<b>To:</b> Mike Jones <Michael.Jones@microsoft.com>; openid-specs-heart@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-heart] Feedback on the HEART OAuth and OpenID Connect profiles from Mike Jones<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hi Mike,<span style="font-size:12.0pt"><o:p></o:p></span></p>
<p>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></o:p></p>
<p><a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.4.2">http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.4.2</a><o:p></o:p></p>
<p>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. <o:p></o:p></p>
<p> -- Justin<o:p></o:p></p>
<div>
<p class="MsoNormal">On 5/8/2016 1:27 AM, Mike Jones wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:14.0pt">OAuth Profile - <a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html">
http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html</a></span></b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.1">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.1</a>
<o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.1"><span style="color:#333333;text-decoration:none">2.1.1.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#FullClient" id="FullClient">
<span style="color:#333333;text-decoration:none">Full Client with User Delegation</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.2">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.2</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.2"><span style="color:#333333;text-decoration:none">2.1.2.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#BrowserClient" id="BrowserClient">
<span style="color:#333333;text-decoration:none">Browser-embedded Client with User Delegation</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.3">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.3</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.1.3"><span style="color:#333333;text-decoration:none">2.1.3.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#DirectClient" id="DirectClient">
<span style="color:#333333;text-decoration:none">Direct Access Client</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.2">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.2</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.2.2"><span style="color:#333333;text-decoration:none">2.2.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#RequestsToTokenEndpoint" id="RequestsToTokenEndpoint">
<span style="color:#333333;text-decoration:none">Requests to the Token Endpoint</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(7) The text “<span lang="EN" style="font-size:10.0pt;font-family:"Verdana",sans-serif">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">JWA</a>
<cite>[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">
http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms</a> – not the JWA spec.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(8) The paragraph including “<span lang="EN" style="font-size:10.0pt;font-family:"Verdana",sans-serif">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3"><span style="color:#333333;text-decoration:none">3.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#ClientRegistration" id="ClientRegistration">
<span style="color:#333333;text-decoration:none">Client Registration</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(9) The profile requires that “<span lang="EN" style="font-size:10.0pt;font-family:"Verdana",sans-serif">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3.2">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3.2</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.3.2"><span style="color:#333333;text-decoration:none">3.2.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#DynamicRegistration" id="DynamicRegistration">
<span style="color:#333333;text-decoration:none">Dynamic Registration</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(12) The profile requires that authorization servers “<span lang="EN" style="font-size:10.0pt;font-family:"Verdana",sans-serif">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4"><span style="color:#333333;text-decoration:none">4.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#ServerProfile" id="ServerProfile">
<span style="color:#333333;text-decoration:none">OAuth 2.0 Server Profile</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(13) The profile requires that “<span lang="EN" style="font-size:10.0pt;font-family:"Verdana",sans-serif">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.1">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.1</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.1"><span style="color:#333333;text-decoration:none">4.1.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#Discovery" id="Discovery">
<span style="color:#333333;text-decoration:none">Discovery</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(16) The profile states “<span lang="EN" style="font-size:10.0pt;font-family:"Verdana",sans-serif">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.2">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.2</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.4.2"><span style="color:#333333;text-decoration:none">4.2.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#JWTBearerTokens" id="JWTBearerTokens">
<span style="color:#333333;text-decoration:none">JWT Bearer Tokens</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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">
https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified-and</a> -
<span lang="EN" style="font-family:"Arial",sans-serif">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.5">http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.5</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#rfc.section.5"><span style="color:#333333;text-decoration:none">5.</span></a>
<a href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html#RequestsToProtectedResource" id="RequestsToProtectedResource">
<span style="color:#333333;text-decoration:none">Requests to the Protected Resource</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:14.0pt">OpenID Connect Profile - <a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html">
http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html</a></span></b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.2"><span style="color:#333333;text-decoration:none">2.</span></a>
<a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#IDTokens" id="IDTokens">
<span style="color:#333333;text-decoration:none">ID Tokens</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(21) The profile says that “<span lang="EN" style="font-size:10.0pt;font-family:"Verdana",sans-serif">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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.3">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.3</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.3"><span style="color:#333333;text-decoration:none">3.</span></a>
<a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#UserInfoEndpoint" id="UserInfoEndpoint">
<span style="color:#333333;text-decoration:none">UserInfo Endpoint</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.4">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.4</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.4"><span style="color:#333333;text-decoration:none">4.</span></a>
<a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#RequestObjects" id="RequestObjects">
<span style="color:#333333;text-decoration:none">Request Objects</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.5">http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.5</a><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN" style="font-family:"Verdana",sans-serif"><a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#rfc.section.5"><span style="color:#333333;text-decoration:none">5.</span></a>
<a href="http://openid.net/specs/openid-heart-openid-connect-1_0-ID1.html#AuthenticationContext" id="AuthenticationContext">
<span style="color:#333333;text-decoration:none">Authentication Context</span></a></span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(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></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(26) Remove the requirement to support the introspection endpoint from this profile, for the same reasons as in (14).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">(27) Remove the requirement to support the revocation endpoint from this profile, for the same reasons as in (15).<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> Thanks all,<o:p></o:p></p>
<p class="MsoNormal"> -- Mike]<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><br>
<br>
<br>
<o:p></o:p></span></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Openid-specs-heart mailing list<o:p></o:p></pre>
<pre><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre>
<pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"><o:p> </o:p></span></p>
</div>
</body>
</html>