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

Torsten Lodderstedt torsten at lodderstedt.net
Fri May 3 05:28:32 UTC 2013

Hi Nat,

the current behaviour is limited. It does not consider persistent authorization grants. Suppose, the user grants a client permanent access to claim a and b in the initial transaction and to claim c in a second transaction. In my opinion, the access token issued in the second transaction must allow the client to query a, b, and c.

Regarding SCIM: are you saying openid connect is inappropriate for enterprise scenarios?


Nat Sakimura <sakimura at gmail.com> schrieb:

>The behavior is correct. The access token represents the "consent".
>obtaining the consent, the purpose specification and data minimization
>principle should apply, thus giving wide range consent at the beginning
>later filtering is not only unadvisable but also sometimes illegal.
>In the enterprise use case, it is deemed that the personal data that
>enterprise has have been granted the user consent out of band so that
>data can be used without explicit consent at runtime. It is an implicit
>consent model. Under such circumstances, filtering at the runtime may
>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/**
>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
>> response of the user info endpoint. Seems a bit strange to me.
>> Moreover, it also requires the client to specify all claims it wants
>> query when obtaining the access token. For our internal applications,
>> would mean to send up to 40 claim names in an authorization although
>> is not authorized by the user but a system policy on a per client
>> This unnecessary increases the request size (URL length).
>> I think a parameter to list the claims a client wants to obtain would
>> very useful and a reasonable extension to the current design.
>> ______________________________**_________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>Nat Sakimura (=nat)
>Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130503/14319162/attachment.html>

More information about the Openid-specs-ab mailing list