Standard 4.1 - Add claim filter to user info request

[Torsten Lodderstedt]

Why is there no way to specify the claims a client wants to obtain in the user info request?

It seems the claim set returned by the user info response is controlled by the scope/claim parameter of the openid authorization request. This means a client must acquire a new access token in order to effectively change the response of the user info endpoint. Seems a bit strange to me.

Moreover, it also requires the client to specify all claims it wants to query when obtaining the access token. For our internal applications, this would mean to send up to 40 claim names in an authorization although access is not authorized by the user but a system policy on a per client base. This unnecessary increases the request size (URL length).

I think a parameter to list the claims a client wants to obtain would be very useful and a reasonable extension to the current design.

[Michael Jones]

This parameter already exists. See http://openid.net/specs/openid-connect-messages-1_0-17.html#ClaimsRequest.

[Torsten Lodderstedt]

This parameter can be sent to the user info endpoint? The member id_token does not make sense in this specific context.

[Michael Jones]

The filtration occurs at the time that you request the access token.

I suppose you could define an extension that passes a "claims" parameter to the UserInfo endpoint as part of the request, but I don't think that it needs to be in the core spec, as filtration is already possible at authentication time.

[Torsten Lodderstedt]

In my opinion, filtration at authentication time is inappropriate. It requires the client to obtain different access tokens (== credentials) in order to query different data sets. I have never seen this pattern in any other API design. The access token typically represents the (complete) authorization of the client and filtration happens as part of the API access. As an example, one might take a look at the portable contacts spec (http://portablecontacts.net/draft-spec.html#anchor12).

What I'm most worried about is that people interpret the OIDC spec in a way that the access token does not represent the client's full authorization on the user info endpoint but just the claims requested in the actual authentication request. This would render an extension parameter to filter the user info response useless. So at least the spec needs a word (or two) on the authorization associated with the access token with regard to the user info endpoint.

[Former user]

I agree with Torsten, and I've had developers confused that they couldn't cut down the data that was coming back. They have to ask for everything up front and are forced to get everything because the API doesn't give another option.

But at the same time, I wouldn't want to expand the UserInfoEndpoint into something as feature-rich as SCIM (because if you're doing that, just use SCIM and call it a day). I think the "fields" parameter of PoCo is actually more appropriate here since you're only ever asking for a single user's information (the "current" user): http://portablecontacts.net/draft-spec.html#anchor15

It would be a simple, perhaps optional, addition. I've been thinking that we might support that on our endpoint anyway as an additional feature.

[Michael Jones]

This was discussed on the 2-May-13 working group call. While we understand the request, we're not going to add this new feature for the upcoming Implementer's Drafts.

People are encouraged to experiment with using the "claims" authorization request parameter syntax as a UserInfo endpoint request parameter as well, to achieve the goal of dynamically selecting a subset of the authorized claims. If experience doing that is positive, we can take this issue up again, based upon data from experience in implementations.

[Nat Sakimura]

The behavior is correct. The access token represents the "consent". When obtaining the consent, the purpose specification and data minimization principle should apply, thus giving wide range consent at the beginning and later filtering is not only unadvisable but also sometimes illegal.

In the enterprise use case, it is deemed that the personal data that the enterprise has have been granted the user consent out of band so that the data can be used without explicit consent at runtime. It is an implicit consent model. Under such circumstances, filtering at the runtime may make sense, but in the enterprise cases, perhaps SCIM endpoint is more appropriate source of employee data.