[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?

regards,
Torsten.



Nat Sakimura <sakimura at gmail.com> schrieb:

>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.
>
>Nat
>
>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
>http://nat.sakimura.org/
>@_nat_en
-------------- 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