[Openid-specs-igov] iGov Notes

Fri Jul 21 18:36:06 UTC 2017

Inline.

> On Jul 21, 2017, at 2:03 PM, Mike Varley <mike.varley at securekey.com> wrote:
> 
> Sarah, Justin, thank-you for the review! I was out of office and am just following up now, sorry for the delay.
> 
> I will have a closer look at the language/spec fixes, but I do have a few questions:
> 
> 1. vot
>  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?  
> 

I disagree with Sarah’s point on VoT: VoT is still in draft, but so is this 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. 

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).

> 2. Data schema
> 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?
> 

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!

> 
> Thanks again for the feedback.
> 
> MV

 — Justin

> 
> From: Openid-specs-igov <openid-specs-igov-bounces at lists.openid.net <mailto:openid-specs-igov-bounces at lists.openid.net>> on behalf of Openid-specs-igov <openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>>
> Reply-To: Sarah Squire <sarah at engageidentity.com <mailto:sarah at engageidentity.com>>
> Date: Wednesday, July 12, 2017 at 7:11 PM
> To: Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>>
> Cc: Openid-specs-igov <openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>>
> Subject: Re: [Openid-specs-igov] iGov Notes
> 
> I likewise had comments. Great work over all. Just a few nits throughout:
> 
> OAuth
> 
> 2.1.3.3. 
> 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?
> 
> 2.1.3.4 
> 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?
> 
> 2.1.4 
> 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
> 
> 3.1.3
> Authorization servers MUST signal to end users that a client was dynamically registered on the authorization screen
> What about manually reviewed/approved clients? Or manually reviewed public clients using PKCE and software statements?
> 
> 3.1.4
> Editorial: “target resource” is not a commonly used term. “Protected resource” would be more consistent with our terminology.
> Additionally, since this is a MUST, it would be good to be prescriptive here. Protected resource, scopes, and refresh token duration, maybe?
> 
> 3.1.5
> If we’re not requiring introspection, we shouldn’t require an introspection endpoint to be listed in the discovery document
> 
> OpenID
> 
> General
> “OpenID IdP,” “OpenID Authorization Server,” “Server,” “OP” and “OpenID Provider” appear to be used interchangeably throughout the document. Let’s pick one.
> 
> 3.4
> Given that Vectors of Trust is still an experimental draft, it seems premature to require a check for it in every authorization request.
> 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?
> The following sentences don’t parse as grammatically valid:
> “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.“
> Suggested replacement text:
> “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.”
> 
> 3.6
> Again, requiring an experimental draft like vot is premature. The example does not include a vot field, as the above text says it must.
> 
> 4.3.1
> Are these intended to be normative MUSTs?
> Inclusion of vot is premature. Inclusion of vtm is likewise premature as no vectors of trust trustmark providers currently exist.
> 
> 4.4
> Example urls should be example.com <http://example.com/> or example.org <http://example.org/>
> 
> Sarah Squire
> Engage Identity
> http://engageidentity.com <http://engageidentity.com/>
> On Tue, Jul 11, 2017 at 8:59 AM, Justin Richer via Openid-specs-igov <openid-specs-igov at lists.openid.net <mailto:openid-specs-igov at lists.openid.net>> wrote:
> I spent some time reading through the documents and had a few comments:
> 
> OAuth:
>  - §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
>  - §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.
>  - §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.
>  - §3.3 should mention PKCE parameters
>  - §3.6 is about protected resource and should go under §4 someplace
> 
> OIDC:
>  - §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)
>  - §3.1 should more strongly encourage subject to be pairwise, with a forward note to privacy considerations
>  - §3.1 optionality of nonce is not specified
>  - §3.6 vot discovery claim is unspecified. Suggest that we include and reference trustmark claims from VoT section 6
>  - §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:
>         “height”: “5’11”
> or
>         “height”: 180
> or
>         “tallness”: true
>  - §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.
> 
>  — Justin
> _______________________________________________
> Openid-specs-igov mailing list
> Openid-specs-igov at lists.openid.net <mailto:Openid-specs-igov at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-igov <http://lists.openid.net/mailman/listinfo/openid-specs-igov>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20170721/5c839f87/attachment-0001.html>