[Openid-specs-ab] Add claim filter to user info request

Nat Sakimura sakimura at gmail.com
Thu May 2 20:46:50 UTC 2013

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.


2013年5月2日木曜日 Torsten Lodderstedt torsten at lodderstedt.net:

> Hi all,
> please take a look at https://bitbucket.org/openid/**
> connect/issue/832/standard-41-**add-claim-filter-to-user-info<https://bitbucket.org/openid/connect/issue/832/standard-41-add-claim-filter-to-user-info>and give your feedback.
> I think the way to control the claim set returned by the user info
> endpoint needs some clarification/improvement.
> regards,
> Torsten.
> ------------------------------**----------------------------
> 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.
> ______________________________**_________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/**mailman/listinfo/openid-specs-**ab<http://lists.openid.net/mailman/listinfo/openid-specs-ab>

Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130503/0e8d0c22/attachment-0001.html>

More information about the Openid-specs-ab mailing list