<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Mike,</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:</p>
<p><a class="moz-txt-link-freetext" 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><br>
</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. <br>
</p>
<p> -- Justin<br>
</p>
<div class="moz-cite-prefix">On 5/8/2016 1:27 AM, Mike Jones wrote:<br>
</div>
<blockquote
cite="mid:SN1PR0301MB16453B882402BB3E9A438836F57F0@SN1PR0301MB1645.namprd03.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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: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;}
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;}
cite
{mso-style-priority:99;
font-style:normal;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@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]-->
<div class="WordSection1">
<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 moz-do-not-send="true"
href="http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html">
http://openid.net/specs/openid-heart-oauth2-1_0-ID1.html</a><o:p></o:p></span></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><a moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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><o:p></o:p></span></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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"
lang="EN">MAY use other asymmetric signature methods listed
in the JSON Web Algorithms (<a moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"
lang="EN">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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"
lang="EN">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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"
lang="EN">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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"
lang="EN">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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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><o:p></o:p></span></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
style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"
lang="EN">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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 style="font-family:"Arial",sans-serif"
lang="EN">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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black"
lang="EN">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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
style="font-family:"Verdana",sans-serif;color:black"
lang="EN"><a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-heart mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</body>
</html>