<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Inline.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 21, 2017, at 2:03 PM, Mike Varley <<a href="mailto:mike.varley@securekey.com" class="">mike.varley@securekey.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">
<div class="">
<div class="">Sarah, Justin, thank-you for the review! I was out of office and am just following up now, sorry for the delay.</div>
<div class=""><br class="">
</div>
<div class="">I will have a closer look at the language/spec fixes, but I do have a few questions:</div>
<div class=""><br class="">
</div>
<div class="">1. vot</div>
<div class=""> vot is still in DRAFT and basing this spec on another DRAFT may cause problems down the road (be premature)... But I believe this aligns closer to the new NIST 800-63-3 specs - so how should we proceed? Should we define it here, or remove it for the currently
supported acr? </div>
<div class=""><br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>I disagree with Sarah’s point on VoT: VoT is still in draft, but so is <i class="">this</i> spec — after all, we’re looking to publish “implementer’s draft” versions right now. VoT is supposed to be moving through the final stages of IETF review and publication now, and it’s arguably much more stable and much further along than iGov even after publication of the implementer’s drafts. </div><div><br class=""></div><div>800-63 tells you about levels but doesn’t give you a mechanism to express those across the wire. VoT gives you a structure and a place to put the data, but doesn’t define the full content of that data in a way that’s actionable here. The upcoming volume -D from NIST should be doing just that (we’ve just started writing that text).</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""><div class=""><div class="">
</div>
<div class="">2. Data schema</div>
<div class="">I agree that a common data schema is needed , but there lies pain and sadness :P Only in that this spec could get bogged down in trying to define that schema, while still making it flexible (like the UserInfo profile - standard fields but room for extensions).
We can certainly take a crack defining at a small set of "claims that make sense" here, but we want to avoid the schema definition rat-hole (I feel). Thoughts on how we keep this meaningful but contained?</div>
<div class=""><br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>Remember that this isn’t a data schema in the traditional sense. Meaningful but contained is fairly simple in the JSON world: define a bunch of things that make sense, and let people add other things that you can ignore. That’s exactly how the UserInfo data model works and this is what we’d be extending. What’s in there right now isn’t really actionable. If someone asks me for a “biometric” scope I have absolutely zero clue as to what I’m allowed to return. Can I just return “bio: much-organic-very-lifeform”? Right now, I could. That’s not interoperability at all, and it’s pointless to have that in there without defining at least part of what it means. Allow others to extend it later, of course, but you can’t really say “use this scope” and not tell me what that scope does on an API. No client would ever ask for it!</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""><div class=""><div class="">
</div>
<div class=""><br class="">
</div>
<div class="">Thanks again for the feedback.</div>
<div class=""><br class="">
</div>
<div class="">MV</div></div></div></div></div></blockquote><div><br class=""></div> — Justin</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""><div class="">
<div class="">
<div id="MAC_OUTLOOK_SIGNATURE" class=""></div>
</div>
</div>
</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 12pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>Openid-specs-igov <<a href="mailto:openid-specs-igov-bounces@lists.openid.net" class="">openid-specs-igov-bounces@lists.openid.net</a>> on behalf of Openid-specs-igov <<a href="mailto:openid-specs-igov@lists.openid.net" class="">openid-specs-igov@lists.openid.net</a>><br class="">
<span style="font-weight:bold" class="">Reply-To: </span>Sarah Squire <<a href="mailto:sarah@engageidentity.com" class="">sarah@engageidentity.com</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>Wednesday, July 12, 2017 at 7:11 PM<br class="">
<span style="font-weight:bold" class="">To: </span>Justin Richer <<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>><br class="">
<span style="font-weight:bold" class="">Cc: </span>Openid-specs-igov <<a href="mailto:openid-specs-igov@lists.openid.net" class="">openid-specs-igov@lists.openid.net</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>Re: [Openid-specs-igov] iGov Notes<br class="">
</div>
<div class=""><br class="">
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;" class="">
<div class="">
<div class="">
<div dir="ltr" class="">I likewise had comments. Great work over all. Just a few nits throughout:
<div class=""><br class="">
</div>
<div class="">
<div class=""><b class="">OAuth</b></div>
<div class=""><br class="">
</div>
<div class="">2.1.3.3. </div>
<div class="">Requirements for a client type that must not be used don't make sense. What does used "by an iGov use case" mean? Does it mean that these clients are not compliant with this spec? If so, why are there normative requirements for them?</div>
<div class=""><br class="">
</div>
<div class="">2.1.3.4 </div>
<div class="">No normative requirements here? No worries that someone will comply with the letter and not the spirit and use this for everything because they’re too lazy to do user authentication?</div>
<div class=""><br class="">
</div>
<div class="">2.1.4 </div>
<div class="">says that native apps have to have an id for each instance contradicting 2.1.3.2 which says that they can have different ids as long as they use PKCE</div>
<div class=""><br class="">
</div>
<div class="">3.1.3</div>
<div class="">Authorization servers MUST signal to end users that a client was dynamically registered on the authorization screen</div>
<div class="">What about manually reviewed/approved clients? Or manually reviewed public clients using PKCE and software statements?<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">3.1.4</div>
<div class="">Editorial: “target resource” is not a commonly used term. “Protected resource” would be more consistent with our terminology.</div>
<div class="">Additionally, since this is a MUST, it would be good to be prescriptive here. Protected resource, scopes, and refresh token duration, maybe?<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">3.1.5</div>
<div class="">If we’re not requiring introspection, we shouldn’t require an introspection endpoint to be listed in the discovery document</div>
<div class=""><br class="">
</div>
<div class=""><b class="">OpenID</b></div>
<div class=""><br class="">
</div>
<div class="">General</div>
<div class="">“OpenID IdP,” “OpenID Authorization Server,” “Server,” “OP” and “OpenID Provider” appear to be used interchangeably throughout the document. Let’s pick one.</div>
<div class=""><br class="">
</div>
<div class="">3.4</div>
<div class="">Given that Vectors of Trust is still an experimental draft, it seems premature to require a check for it in every authorization request.</div>
<div class="">So servers MUST check for vtr and acr, but they only MAY respond to it. If they know they can’t/won’t respond, why make them check?<br class="">
</div>
<div class="">The following sentences don’t parse as grammatically valid:<br class="">
</div>
<div class="">“OpenID Providers MAY provide the vot and contain valid values from the Vectors of Trust standard.The vtr and contain valid values from the Vectors of Trust standard.“</div>
</div>
Suggested replacement text:<br class="">
“If vtr and acr parameters are present in a request, OpenID Providers MUST ignore the acr request, and MAY respond to the vtr request with a vot field describing the context of the authentication event as described in the Vectors of Trust standard.”<br class="">
<br class="">
3.6<br class="">
Again, requiring an experimental draft like vot is premature. The example does not include a vot field, as the above text says it must.<br class="">
<br class="">
4.3.1
<div class="">Are these intended to be normative MUSTs?<br class="">
Inclusion of vot is premature. Inclusion of vtm is likewise premature as no vectors of trust trustmark providers currently exist.<br class="">
<br class="">
4.4<br class="">
Example urls should be <a href="http://example.com/" class="">example.com</a> or <a href="http://example.org/" class="">
example.org</a></div>
</div>
<div class="gmail_extra"><br clear="all" class="">
<div class="">
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr" class="">
<div style="color:rgb(136,136,136)" class="">Sarah Squire</div>
<div style="color:rgb(136,136,136)" class="">Engage Identity</div>
<div style="color:rgb(136,136,136)" class=""><a href="http://engageidentity.com/" style="color:rgb(17,85,204)" target="_blank" class="">http://engageidentity.com</a></div>
</div>
</div>
</div>
<br class="">
<div class="gmail_quote">On Tue, Jul 11, 2017 at 8:59 AM, Justin Richer via Openid-specs-igov
<span dir="ltr" class=""><<a href="mailto:openid-specs-igov@lists.openid.net" target="_blank" class="">openid-specs-igov@lists.openid.net</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I spent some time reading through the documents and had a few comments:<br class="">
<br class="">
OAuth:<br class="">
- §2.1.3 should come earlier in the document, maybe even as its own upper-level section such as §2.1, shifting everything else down<br class="">
- §2.1.3.3 prohibits use of implicit or browser based clients, but other parts of the document reference these flows. Also this paragraph is very long and detailed for something that’s prohibited.<br class="">
- §2.1.5 says that all clients must have keys until the end where it says one exception. This can probably be rearranged to be more clear.<br class="">
- §3.3 should mention PKCE parameters<br class="">
- §3.6 is about protected resource and should go under §4 someplace<br class="">
<br class="">
OIDC:<br class="">
- §2.1 “prompt” parameter with a single value is overly restrictive, requirement should be removed or justified (I suggest removed — it’s not explained and I don’t see a good reason for it anyway)<br class="">
- §3.1 should more strongly encourage subject to be pairwise, with a forward note to privacy considerations<br class="">
- §3.1 optionality of nonce is not specified<br class="">
- §3.6 vot discovery claim is unspecified. Suggest that we include and reference trustmark claims from VoT section 6<br class="">
- §4.2 The scopes and their resulting claims need more explanation and examples. We need a data model and schema. If someone asks for “bio” do I respond with:<br class="">
“height”: “5’11”<br class="">
or<br class="">
“height”: 180<br class="">
or<br class="">
“tallness”: true<br class="">
- §5 the last paragraph needs to be removed or rewritten. Here we just want to justify why pairwise is a good idea — so explain that, don’t add more non-requirements.<br class="">
<br class="">
— Justin<br class="">
______________________________<wbr class="">_________________<br class="">
Openid-specs-igov mailing list<br class="">
<a href="mailto:Openid-specs-igov@lists.openid.net" class="">Openid-specs-igov@lists.<wbr class="">openid.net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-igov" rel="noreferrer" target="_blank" class="">http://lists.openid.net/<wbr class="">mailman/listinfo/openid-specs-<wbr class="">igov</a><br class="">
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</span>
</div>
</div></blockquote></div><br class=""></div></body></html>