[Openid-specs-igov] iGov Notes

[Mike Varley]

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?

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?


Thanks again for the feedback.

MV

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

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