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

Mike Varley mike.varley at securekey.com
Thu Mar 23 19:02:01 UTC 2017 

Thanks Justin,

Sometimes governments and large organizations that may want to act as IdPs have security concerns around "discoverable" interfaces. I'm not defending these concerns as rational, only pointing out that the concerns exist :)

The other concerns would be around Dynamic Registration and how this would be protected from general use - commercial IdPs may need business agreements and contracts signed before a client can register.

I think these concerns can be mitigated with some additional content in the Security Considerations section rather than additional MAYs in the spec... Something to the affect of:

Discovery

  *   discovery does not pose a serious risk to API endpoints so long as the endpoints are protected "properly" (find a good best practices reference for that). Endpoints accessible via the Internet are discoverable anyway, OAuth/OpenID discovery simply provides a standard, programatic way for Clients to get configuration. (Is there a SAML metadata discovery model we can reference?)

Dynamic Registration

  *   Similar to Discovery, Dynamic Registration allows for authorized Clients to on-board programatically without administrative intervention. This is particularly important in ecosystems with many potential Clients, including Mobile Apps acting as independent Clients. OPs  may protect their Dynamic Registration endpoints by requiring clients to present credentials that the OP would recognize as authorized participants. See section 3 of the Dynamic Discovery Spec [ ... ]

Would others see the above as useful and sufficient?

MV

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Wednesday, March 22, 2017 at 2:15 PM
To: "Grassi, Paul A. (Fed)" <paul.grassi at nist.gov<mailto:paul.grassi at nist.gov>>, 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>>
Cc: Dmitry Schupak <Dmitry.Schupak at securekey.com<mailto:Dmitry.Schupak at securekey.com>>
Subject: Re: [Openid-specs-igov] feedback on current pull request


On a couple points below:

The intent of the dynamic registration was to require servers to support it, not to require clients to use it. If that's unclear, then it should be propagated to HEART as well, but I think that the current text gives the right guidance. Clients could always be statically configured, of course.

Discovery and registration are separate issues. I see zero argument for not having a discovery endpoint, regardless of how we handle registration.

 -- Justin

On 3/21/2017 7:19 PM, Grassi, Paul A. (Fed) via Openid-specs-igov wrote:
Some comments inline.  Hoping others will chime in. I am happy to add agreed changes to the PR or we can merge and have Mike go at it.

From: Openid-specs-igov <openid-specs-igov-bounces at lists.openid.net><mailto:openid-specs-igov-bounces at lists.openid.net> on behalf of Mike Varley via Openid-specs-igov <openid-specs-igov at lists.openid.net><mailto:openid-specs-igov at lists.openid.net>
Reply-To: Mike Varley <mike.varley at securekey.com><mailto:mike.varley at securekey.com>
Date: Tuesday, March 21, 2017 at 8:39 AM
To: Openid-specs-igov <openid-specs-igov at lists.openid.net><mailto:openid-specs-igov at lists.openid.net>
Cc: Dmitry Schupak <Dmitry.Schupak at securekey.com><mailto:Dmitry.Schupak at securekey.com>
Subject: [Openid-specs-igov] feedback on current pull request

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) PG - Yes

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

2.1.1
  - recommend line break of response Location and GET request (legibility) PG - yes
  - 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? PG- not seeing where this is in 2.1.1, but generally I am ok with this.  JOSE supports.

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

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

2.1.4
  - contradicts 2.1.3.2: "must use either..." PG – I defer, but the whole of 2.1.4 says register or and use PCKE.  If that is too confusing we can fix but I am not strong on the nuance here.  John/Justin?
  - prefer to allow static configuration as well, even for native clients - current language is too restrictive and requires dynamic registration. Pg - agree

3.1.3
  - client_credentials grant type not defined in section 2? PG – should be fixed.

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 PG – fair point.  Defer to group

3.1.5
  - "MUST provide a discovery endpoint" -- are we making dynamic registration a requirement? Why? PG – I like the flexibility, but I am not hard pressed.  I also think we are missing something around software statements or trust anchors to know you are discovering something good.

3.2.2
  - example scope - maybe update to egov use example (no 'medications') PG – hah, good catch.

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) PG – save for group discussion.  In an email thread we decided we needed both, but we need to discuss the use case together.

2.3 and 3.1 are different
  - maybe add REQUIRED and OPTIONAL to 3.1 PG - yes
  - vot definition missing   pg – crap.  Good catch

3.2
  - need to require an EC algorithm? (again, better support on native clients...?)  Pg – if we agree above we agree here.

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 pg – another good group discussion
  - 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






_______________________________________________
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/20170323/c2fb55a1/attachment-0001.html>

More information about the Openid-specs-igov mailing list