[Openid-specs-igov] iGov Notes

Grassi, Paul A. (Fed) paul.grassi at nist.gov
Fri Jul 28 18:42:00 UTC 2017


Mike, that would be great. Have at it!

I don’t have an issue with VOT knowing the plan the IETF has with the document, and the amount of time it will take us to get a proper VOT structure for international use cases.

From: Openid-specs-igov <openid-specs-igov-bounces at lists.openid.net> on behalf of Mike Varley via Openid-specs-igov <openid-specs-igov at lists.openid.net>
Reply-To: Mike Varley <mike.varley at securekey.com>
Date: Thursday, July 27, 2017 at 3:55 PM
To: Justin Richer <jricher at mit.edu>
Cc: Openid-specs-igov <openid-specs-igov at lists.openid.net>
Subject: Re: [Openid-specs-igov] iGov Notes

Yes I hope to incorporate the comments provided; Paul any issues?

Any further comments on the 'vot' issue?

MV

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Wednesday, July 26, 2017 at 11:28 AM
To: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Cc: Mike Varley <mike.varley at securekey.com<mailto:mike.varley at securekey.com>>, 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 missed the first part of this week’s call, but are the comments below from me and Sarah going to be addressed and incorporated? I’d just like to know what the plan from the WG is so I can better inform others of our progress and timeline.

Thanks!
 — Justin

On Jul 21, 2017, at 2:36 PM, Justin Richer via Openid-specs-igov <openid-specs-igov at lists.openid.net<mailto:openid-specs-igov at lists.openid.net>> wrote:

Inline.

On Jul 21, 2017, at 2:03 PM, Mike Varley <mike.varley at securekey.com<mailto: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


_______________________________________________
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/20170728/1d5e791f/attachment-0001.html>


More information about the Openid-specs-igov mailing list