<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body 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 http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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>
</body>
</html>