[Openid-specs-igov] Oauth2 spec update pushed

Mike Varley mike.varley at securekey.com
Wed Dec 20 15:02:57 UTC 2017 

Thank-you for the review Justin - and I apologize to everyone for missing the last call.

Given the holiday schedule, when will be the next call? Jan 10? I can hopefully incorporate the changes below into the doc for then.

MV

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Wednesday, December 13, 2017 at 5:30 PM
To: Mike Varley <mike.varley at securekey.com<mailto:mike.varley at securekey.com>>
Cc: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>, "Paul A. Grassi" <paul.grassi at nist.gov<mailto:paul.grassi at nist.gov>>, Openid-specs-igov <openid-specs-igov at lists.openid.net<mailto:openid-specs-igov at lists.openid.net>>
Subject: Re: [Openid-specs-igov] Oauth2 spec update pushed

Comments on the OIDC profile updates:

Overall looks good, seems to address the most of the comments previously raised. A few additional comments:

 - §3.1: under “sub”, “HIGHLY RECOMMENDED” is not a normative term defined by RFC2119. Change to “RECOMMENDED”, and perhaps provide a forward link to the privacy considerations section mentioned.
 - §3.1: under “nonce”, typo “REQUIRED if if provided”, should be “REQUIRED if provided”, or really just “REQUIRED” since it’s required to be provided by the previous section
 - §3.1: under “auth_time”, obviously normative requirement needs to be decided by the group; I’m on the fence as it’s very useful when authentication is an interactive event (as it is in most IdPs today) but less so when it’s continuous (as in the case of things like Google and a growing number of others)
 - §3.1: example VoT value doesn’t fit VoT syntax. A better example here would be “P1.C1” (using the NIST values from 800-63-D)
 - §3.4: I’m a little worried by the “processed accordingly language if we don’t say what that processing will take
 - §3.4: it’s not accurate to require “values from the standard”, since values can and will be defined external to the standard document; suggest fixing both this and the previous point by rewording this paragraph:
If the vtr (Vectors of Trust Request) value is present in the authorization request as defined in the [Vectors of Trust standard], the OpenID Provider SHOULD respond with a valid vot value as defined in [section 3.1]. Both the vtr and vot MUST contain values in accordance with the [Vectors of Trust standard]. These values MAY be those defined in the [Vectors of Trust standard] directly or MAY be from a compatible The OpenID Provider MAY require the user to re-authenticate, provide a second factor, or perform another action in order to fulfill the state requested in the vtr.
 - §3.6: example of “vot” discovery value is found in the VoT spec under the discovery section; acr example in the OpenID Connect discovery spec
 - §4.3.1: this was questioned in the review before, and this is not a usage that’s specified by the VoT draft document. VoT isn’t about attributes so much as the overall transaction, so it doesn’t fit here. Suggest we drop section 4.3.1 and its associated fields in the example in 4.4. Attribute metadata is important work but I don’t think we’ve had enough discussion in this group to include it here yet.
 - §5: last paragraph doesn’t add anything, as mentioned in previous review. Suggest removing and replacing with:
5.1 Pairwise identifiers
Pairwise identifiers specified in [OpenID Connect section 8] allow an OpenID Provider to represent a single user with a different subject identifier for every RP the user connects to. This technique can help mitigate correlation of a user between multiple RPs by preventing the RPs from using the subject identifier (the “sub” claim in the ID token) to track a user between different sites and applications. Use of pairwise identifiers does not prevent RPs from correlating data based on other identifying attributes such as names, email addresses, document numbers, or other attributes. However, since not all transactions require access to these attributes, but a subject identifier is always required, a pairwise identifier will aid in protecting the privacy of end users as they navigate the system.


On Dec 12, 2017, at 7:08 AM, Mike Varley via Openid-specs-igov <openid-specs-igov at lists.openid.net<mailto:openid-specs-igov at lists.openid.net>> wrote:

I am in an all-day meeting but I am hoping to join the call.

The OpenID Connect profile was updated on the weekend; I don't expect people to review for the call but I can go through the changes.

Draft iGov Profile.
<https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?Submit=Submit&format=ascii&mode=html&type=ascii&url=https://bitbucket.org/openid/igov/raw/master/openid-igov-profile.xml>


MV



On 2017-12-11, 1:22 PM, "Openid-specs-igov on behalf of John Bradley via 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 at lists.openid.net<mailto:openid-specs-igov at lists.openid.net>> wrote:

Yes, I am planning on being on the call.


On Dec 11, 2017, at 3:11 PM, Grassi, Paul A. (Fed) via Openid-specs-igov <openid-specs-igov at lists.openid.net<mailto:openid-specs-igov at lists.openid.net>> wrote:

Hi all,
I need to miss tomorrow due to an FAA meeting. John/Adam, will you be on?

On 11/28/17, 12:18 PM, "Grassi, Paul A. (Fed)" <paul.grassi at nist.gov<mailto:paul.grassi at nist.gov>> wrote:

  Hi all,
  Per the meeting today, please review the documents by next Tuesday, offering any remaining comments on the distro. We are working towards initiating a new vote by our next meeting in 2 weeks.
  Thanks!
  Paul, Adam, John

  On 10/16/17, 9:51 AM, "Openid-specs-igov on behalf of Mike Varley via 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 at lists.openid.net<mailto:openid-specs-igov at lists.openid.net>> wrote:

      I have pushed in the change to the OAuth2 spec - it incorporates the comments from the list, but there are still details that need fixing (protocol samples for example).

      Since there is still active discussion about the spec I felt it best to get the most recent published so we can discuss off that version.

      Here is a rendered version link:
      https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxml2rfc.tools.ietf.org%2Fcgi-bin%2Fxml2rfc.cgi%3FSubmit%3DSubmit%26format%3Dascii%26mode%3Dhtml%26type%3Dascii%26url%3Dhttps%3A%2F%2Fbitbucket.org%2Fopenid%2Figov%2Fraw%2Fmaster%2Fopenid-igov-oauth2.xml&data=02%7C01%7Cpaul.grassi%40nist.gov%7Ce99cf6f0e04544da752c08d5149cf71e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636437586762462724&sdata=igCWIXlryrnMurhMku%2FqA9cCotOsnVlt1GWXjI%2B0fEs%3D&reserved=0


      Thanks,

      MV

      _______________________________________________
      Openid-specs-igov mailing list
      Openid-specs-igov at lists.openid.net<mailto:Openid-specs-igov at lists.openid.net>
      https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-igov&data=02%7C01%7Cpaul.grassi%40nist.gov%7Ce99cf6f0e04544da752c08d5149cf71e%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636437586762462724&sdata=5305KduoQgycO3Qhj17w4h4EYtCzew8cJk9FMmfasXk%3D&reserved=0




_______________________________________________
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/20171220/41c8cf59/attachment-0001.html>

More information about the Openid-specs-igov mailing list