<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; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div>Thanks Justin,</div>
<div><br>
</div>
<div>Sometimes governments and large organizations that may want to act as IdPs have security concerns around "discoverable" interfaces. I'm not defending these concerns as rational, only pointing out that the concerns exist :)</div>
<div><br>
</div>
<div>The other concerns would be around Dynamic Registration and how this would be protected from general use - commercial IdPs may need business agreements and contracts signed before a client can register.</div>
<div><br>
</div>
<div>I think these concerns can be mitigated with some additional content in the Security Considerations section rather than additional MAYs in the spec... Something to the affect of:</div>
<div><br>
</div>
<div>Discovery</div>
<ul>
<li>discovery does not pose a serious risk to API endpoints so long as the endpoints are protected "properly" (find a good best practices reference for that). Endpoints accessible via the Internet are discoverable anyway, OAuth/OpenID discovery simply provides
a standard, programatic way for Clients to get configuration. (Is there a SAML metadata discovery model we can reference?)</li></ul>
<div>Dynamic Registration</div>
<ul>
<li>Similar to Discovery, Dynamic Registration allows for authorized Clients to on-board programatically without administrative intervention. This is particularly important in ecosystems with many potential Clients, including Mobile Apps acting as independent
Clients. OPs may protect their Dynamic Registration endpoints by requiring clients to present credentials that the OP would recognize as authorized participants. See section 3 of the Dynamic Discovery Spec [ ... ]</li></ul>
<div>Would others see the above as useful and sufficient?</div>
<div><br>
</div>
<div>MV</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Justin Richer <<a href="mailto:jricher@mit.edu">jricher@mit.edu</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, March 22, 2017 at 2:15 PM<br>
<span style="font-weight:bold">To: </span>"Grassi, Paul A. (Fed)" <<a href="mailto:paul.grassi@nist.gov">paul.grassi@nist.gov</a>>, Mike Varley <<a href="mailto:mike.varley@securekey.com">mike.varley@securekey.com</a>>, Openid-specs-igov <<a href="mailto:openid-specs-igov@lists.openid.net">openid-specs-igov@lists.openid.net</a>><br>
<span style="font-weight:bold">Cc: </span>Dmitry Schupak <<a href="mailto:Dmitry.Schupak@securekey.com">Dmitry.Schupak@securekey.com</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-igov] feedback on current pull request<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div bgcolor="#FFFFFF" text="#000000">
<p>On a couple points below: <br>
</p>
<p>The intent of the dynamic registration was to require servers to support it, not to require clients to use it. If that's unclear, then it should be propagated to HEART as well, but I think that the current text gives the right guidance. Clients could always
be statically configured, of course.<br>
</p>
<p>Discovery and registration are separate issues. I see zero argument for not having a discovery endpoint, regardless of how we handle registration.
<br>
</p>
<p> -- Justin<br>
</p>
<div class="moz-cite-prefix">On 3/21/2017 7:19 PM, Grassi, Paul A. (Fed) via Openid-specs-igov wrote:<br>
</div>
<blockquote cite="mid:50365664-9D3F-4929-97A7-1608B24C1887@nist.gov" type="cite">
<meta name="Title" content="">
<meta name="Keywords" content="">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Calibri;}
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;}
span.EmailStyle17
{mso-style-type:personal;
font-family:Calibri;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.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>
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Some comments inline. Hoping others will chime in. I am happy to add agreed changes to the PR or we can merge and have Mike go at it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From: </span></b><span style="color:black">Openid-specs-igov
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-igov-bounces@lists.openid.net">
<openid-specs-igov-bounces@lists.openid.net></a> on behalf of Mike Varley via Openid-specs-igov
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-igov@lists.openid.net">
<openid-specs-igov@lists.openid.net></a><br>
<b>Reply-To: </b>Mike Varley <a class="moz-txt-link-rfc2396E" href="mailto:mike.varley@securekey.com">
<mike.varley@securekey.com></a><br>
<b>Date: </b>Tuesday, March 21, 2017 at 8:39 AM<br>
<b>To: </b>Openid-specs-igov <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-igov@lists.openid.net">
<openid-specs-igov@lists.openid.net></a><br>
<b>Cc: </b>Dmitry Schupak <a class="moz-txt-link-rfc2396E" href="mailto:Dmitry.Schupak@securekey.com">
<Dmitry.Schupak@securekey.com></a><br>
<b>Subject: </b>[Openid-specs-igov] feedback on current pull request<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New
Roman""><o:p> </o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Here is SecureKey's feedback on Paul's current version(s) of the specs. (note I believe some of the corrections I point out are on content I originally authored... So ...)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we accept Paul's pull request I would be happy to help with some of the edits.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I may not be able to make today's call, but I think Dmitry Schupak should be there - and I will follow up on the list.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks all.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">MV <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">OAuth 2.0 Spec<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">==============<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Abstract: <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> " specifically applicable to (but not limited to) consumer-to-government deployments." (wording change)
<span style="color:red">PG - Yes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Intro<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> " informed by the HEART..." -> influenced? <span style="color:red">
PG - Yes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"> extra "."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2.1.1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - recommend line break of response Location and GET request (legibility)
<span style="color:red">PG - yes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"> - would like to add EC to the required list of supported algorithms... is there a reason not to? The reason to (possibly) require this is for better mobile support?
<span style="color:red">PG- not seeing where this is in 2.1.1, but generally I am ok with this. JOSE supports.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2.1.3.3<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - "This client type MUST NOT be used by any iGov use case." move to top.
<span style="color:red">PG - yes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2.1.3.4<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - "This client type MUST NOT be used by any iGov use case." move to top.
<span style="color:red">PG - yes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2.1.4<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - contradicts 2.1.3.2: "must use either..." <span style="color:red">
PG – I defer, but the whole of 2.1.4 says register or and use PCKE. If that is too confusing we can fix but I am not strong on the nuance here. John/Justin?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"> - prefer to allow static configuration as well, even for native clients - current language is too restrictive and requires dynamic registration.
<span style="color:red">Pg - agree<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.1.3<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - client_credentials grant type not defined in section 2? <span style="color:red">
PG – should be fixed.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.1.3<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - "Authorization servers MUST signal to end users that a client was dynamically registered
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> on the authorization screen. " -> don't know what this means. An example would help clarify what is expected from the AuthZ <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> server, and why the message to the end user is important
<span style="color:red">PG – fair point. Defer to group<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.1.5<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - "MUST provide a discovery endpoint" -- are we making dynamic registration a requirement? Why?
<span style="color:red">PG – I like the flexibility, but I am not hard pressed. I also think we are missing something around software statements or trust anchors to know you are discovering something good.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.2.2<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - example scope - maybe update to egov use example (no 'medications')
<span style="color:red">PG – hah, good catch.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">OIDC Profile<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">============<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2.1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - vtr and acr_values? why both? And to clarify, what is a server to do if both values are present in a request? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Why would a client use one over the other? Etc... (we support the use of vot)
<span style="color:red">PG – save for group discussion. In an email thread we decided we needed both, but we need to discuss the use case together.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2.3 and 3.1 are different<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - maybe add REQUIRED and OPTIONAL to 3.1 <span style="color:red">
PG - yes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"> - vot definition missing <span style="color:red">pg – crap. Good catch<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.2<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - need to require an EC algorithm? (again, better support on native clients...?)
<span style="color:red">Pg – if we agree above we agree here.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.3<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - should we define the (minimum or recommended) content that is signed in a request object?
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - need to define REQUIRED algorithm like token request?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - "must accept request objects signed with the <i>client's</i> public key" (server's -> client's) <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.4 + 3.5<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - need more guidence around acr/amr/vot. How do we use and process these? What is their relationship, <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> and how does a server/client make use of these values if they are all present, possibly contradictory?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3.6.1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - do we need to add something to JWA? where is an appropriate place to descibe PBKDF2 + scrypt + bcrypt<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - PBKDF2 is in the JWA doc (somewhere) so should we make this the baseline REQUIRED and then worry about the others as needed?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">4.2 <span style="color:red">pg – another good group discussion<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"> - should we add REQUIRED OPTIONAL OPTIONAL on these additional scopes?
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - at their current high level, are these definitions useful? (i.e., I think we either add clearer definitions here, or remove them)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:black">From: </span></b><span style="color:black">Openid-specs-igov <<a moz-do-not-send="true" href="mailto:openid-specs-igov-bounces@lists.openid.net">openid-specs-igov-bounces@lists.openid.net</a>> on behalf of Openid-specs-igov
<<a moz-do-not-send="true" href="mailto:openid-specs-igov@lists.openid.net">openid-specs-igov@lists.openid.net</a>><br>
<b>Reply-To: </b>"Grassi, Paul A. (Fed)" <<a moz-do-not-send="true" href="mailto:paul.grassi@nist.gov">paul.grassi@nist.gov</a>><br>
<b>Date: </b>Wednesday, March 1, 2017 at 6:21 PM<br>
<b>To: </b>Openid-specs-igov <<a moz-do-not-send="true" href="mailto:openid-specs-igov@lists.openid.net">openid-specs-igov@lists.openid.net</a>><br>
<b>Subject: </b>[Openid-specs-igov] PR<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Times New
Roman""><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF
4.5pt;padding:0in 0in 0in
4.0pt;margin-left:3.75pt;margin-right:0in" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Lots of changes in the current PR, namely adding an OAuth profile.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Many comments/question in the source and likely many issues/questions to resolve around LOA/acr/vot, etc.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks and credit to Justin as the latest HEART versions serve as the basis for the breakdown and the new format. Some lingering legacy sections from Mike’s version that may be ok as they are or could be
subsumed elsewhere, but all topics for the next meeting.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I don’t plan on merging my own PR, but if we don’t care too much at QAQC at this point (since the meeting will be a QAQC beat-down) then I am happy to merge. Or, following John’s approach to the live HTML
links you can always hit:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OIDC: <a moz-do-not-send="true" href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/paul_grassi/igov/raw/pre-id/openid-igov-profile.xml">
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/paul_grassi/igov/raw/pre-id/openid-igov-profile.xml</a></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">OAath2: <a moz-do-not-send="true" href="https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/paul_grassi/igov/raw/pre-id/openid-igov-oauth2.xml">
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/paul_grassi/igov/raw/pre-id/openid-igov-oauth2.xml</a></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset> <br>
<pre wrap="">_______________________________________________
Openid-specs-igov mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-igov@lists.openid.net">Openid-specs-igov@lists.openid.net</a><a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-igov">http://lists.openid.net/mailman/listinfo/openid-specs-igov</a></pre>
</blockquote>
<br>
</div>
</div>
</blockquote>
</span>
</body>
</html>