[Openid-specs-igov] Oauth2 spec update pushed

Tue Jan 9 17:01:35 UTC 2018

A thought on claim metadata syntax:

We can’t really add things to the main document without breaking compatibility in really bad ways, so this would need to be in its own structure. But the thought would be to do something for each claim like:

_claim_metadata: {
  “name”: { src: foo, locale: bar, enc: baz },
  “bio”: {locale: batman” … }
  ...
}

It’s basically the same info in what’s there now but in a single block structure. I was never a fan of how the claim source is set up in OIDC. 

But the more I think about it, I it’s reasonable that the RP might want to get this from a separate call all together, so we might want to step away from defining it at all because a different structure could be defined. Still worth mentioning that attribute metadata is a thing and it doesn’t get fully covered here. 

 — Justin

> On Jan 9, 2018, at 10:35 AM, Mike Varley via Openid-specs-igov <openid-specs-igov at lists.openid.net> wrote:
> 
> I have updated the spec wit Justin's corrections + suggestions.
> 
> To discuss:
> 
> * auth_time being required or not (I marked it as REQUIRED),
> * scope profiles (particularly 'bio')
> * section 4.3.1 describes the 'confidence level' that an OP has on the values its providing... 
>  An important concept but maybe not for this spec?
> 
> 
> Rendered doc can be found here:
> 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
> 
> Thanks,
> 
> MV
> 
> From:  Openid-specs-igov <openid-specs-igov-bounces at lists.openid.net> on behalf of Openid-specs-igov <openid-specs-igov at lists.openid.net>
> Reply-To:  Mike Varley <mike.varley at securekey.com>
> Date:  Wednesday, December 20, 2017 at 10:02 AM
> To:  Justin Richer <jricher at mit.edu>
> Cc:  Openid-specs-igov <openid-specs-igov at lists.openid.net>
> Subject:  Re: [Openid-specs-igov] Oauth2 spec update pushed
> 
> 
>> 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>
>> Date: Wednesday, December 13, 2017 at 5:30 PM
>> To: Mike Varley <mike.varley at securekey.com>
>> Cc: John Bradley <ve7jtb at ve7jtb.com>, "Paul A. Grassi" <paul.grassi at nist.gov>, Openid-specs-igov <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> 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 on behalf of
>>> 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> 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> 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 on behalf of
>>> 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
>>>     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
>>> http://lists.openid.net/mailman/listinfo/openid-specs-igov
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Openid-specs-igov mailing list
>>> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-igov