[Openid-specs-igov] feedback on current pull request

[Mike Varley]

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

If we accept Paul's pull request I would be happy to help with some of the edits.

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.

Thanks all.

MV


OAuth 2.0 Spec
==============
Abstract:
   " specifically applicable to (but not limited to) consumer-to-government deployments." (wording change)

Intro
  " informed by the HEART..." -> influenced?
  extra "."

2.1.1
  - recommend line break of response Location and GET request (legibility)
  - 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?

2.1.3.3
  - "This client type MUST NOT be used by any iGov use case." move to top.

2.1.3.4
  - "This client type MUST NOT be used by any iGov use case." move to top.

2.1.4
  - contradicts 2.1.3.2: "must use either..."
  - prefer to allow static configuration as well, even for native clients - current language is too restrictive and requires dynamic registration.

3.1.3
  - client_credentials grant type not defined in section 2?

3.1.3
  - "Authorization servers MUST signal to end users that a client was dynamically registered
     on the authorization screen. " -> don't know what this means. An example would help clarify what is expected from the AuthZ
      server, and why the message to the end user is important

3.1.5
  - "MUST provide a discovery endpoint" -- are we making dynamic registration a requirement? Why?

3.2.2
  - example scope - maybe update to egov use example (no 'medications')

OIDC Profile
============

2.1
  - vtr and acr_values? why both?  And to clarify, what is a server to do if both values are present in a request?
     Why would a client use one over the other? Etc...  (we support the use of vot)

2.3 and 3.1 are different
  - maybe add REQUIRED and OPTIONAL to 3.1
  - vot definition missing

3.2
  - need to require an EC algorithm? (again, better support on native clients...?)

3.3
  - should we define the (minimum or recommended) content that is signed in a request object?
  - need to define REQUIRED algorithm like token request?
  - "must accept request objects signed with the client's public key" (server's -> client's)

3.4 + 3.5
  - need more guidence around acr/amr/vot. How do we use and process these? What is their relationship,
     and how does a server/client make use of these values if they are all present, possibly contradictory?

3.6.1
  - do we need to add something to JWA? where is an appropriate place to descibe PBKDF2 + scrypt + bcrypt
  - PBKDF2 is in the JWA doc (somewhere) so should we make this the baseline REQUIRED and then worry about the others as needed?

4.2
  - should we add REQUIRED OPTIONAL OPTIONAL on these additional scopes?
  - at their current high level, are these definitions useful? (i.e., I think we either add clearer definitions here, or remove them)


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: "Grassi, Paul A. (Fed)" <paul.grassi at nist.gov<mailto:paul.grassi at nist.gov>>
Date: Wednesday, March 1, 2017 at 6:21 PM
To: Openid-specs-igov <openid-specs-igov at lists.openid.net<mailto:openid-specs-igov at lists.openid.net>>
Subject: [Openid-specs-igov] PR

Lots of changes in the current PR, namely adding an OAuth profile.

Many comments/question in the source and likely many issues/questions to resolve around LOA/acr/vot, etc.

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.

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:

OIDC:  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

OAath2: 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20170321/05705a10/attachment.html>