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

Sat May 4 20:52:44 UTC 2013

Hi Mike,

we will do this and share our experiences with the working group.

Independent of my feature request, I still see the need for some
clarification in the spec regarding the actual claim set a client may
expect when requesting user info (my general note). In my opinion, the
desired behavior is not clearly defined, which might cause
interoperability problems. We implemented the behavor I described below.

regards,
Torsten.

Am 04.05.2013 19:33, schrieb Mike Jones:
>
> Hi Torsten,
>
> Please consider implementing what the working group suggested when it
> decided not to take action in this regard now. That is:
>
> 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.
>
> It’s not that the working group thought that your request didn’t make
> sense. It’s that it felt that there wasn’t enough experience with this
> to standardize a feature now. If your, and possibly other’s
> experiences are positive, this could change in the future.
>
> -- Mike
>
> *From:*openid-specs-ab-bounces at lists.openid.net
> [mailto:openid-specs-ab-bounces at lists.openid.net] *On Behalf Of
> *Torsten Lodderstedt
> *Sent:* Saturday, May 04, 2013 4:52 AM
> *To:* Nat Sakimura
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Add claim filter to user info request
>
> Hi Nat,
>
> Am 04.05.2013 07:38, schrieb Nat Sakimura:
>
>     "Permanent access to claim a and b" has to be bound to a purpose.
>     If at a later date, when additional grant to "claim c" is made, it
>     is likely that the purpose would be different, since if the
>     purpose was the same, the grant request for c were requested to
>     start with a and b. The access token issued in the second
>     transaction may allow the client to query a, b, and c only if the
>     purpose was the same AND the subject did understand that they were
>     taken together.
>
>
> Let's assume this is the case. In order to support such a case, the
> spec should state that the actual claim set returned in a user info
> response is based on the authorization grant underlying the access
> token, which might differ from the claim set requested in the
> transaction used to obtain the access token.
>
> As a general note:
> We should not mix the authorization request to access data and the
> actual attribute/claim query. In contrast to OpenID 2.0./AX those
> aspects could and should be distinguished in Connect. In my opinion,
> the user info endpoint should always allow the client to obtain _all_
> claims it is authorized for. This should hold true independent of the
> way the consent is given (inbound or out of bound).
>
> The OAuth/Connect request "just" triggers login and, if needed, user
> consent. Claims can be queried at any time afterwards either be using
> the access token issued as result of the login request or using
> another access token obtained using a refresh token issued in this
> transaction as well.
>
> Treating the authorization request and the attribute query as the same
> has some unpleasant implications.
>
> 1) The client has to perform additional OpenID requests in order to
> change the user info response.
> a) request to end-user authorization endpoint with changed claim set
> b) exchange auth code id and access token
> c) access user info endpoint (if data are not transfered in id token)
> This has a negative impact on the application's performance. Moreover,
> performing such a request full screen will yield a bad user
> experience. Performing it in a (invisible or small) iframe will
> probably fall prey to the browser's 3rd party cookie policy.
>
> 2) the OP has to maintain transactional state with every code, access
> and refresh token, resulting in a more complex and less scalable
> implementation.
>
> In our implementation, we store the user's consent in a database and
> ask the user for another consent only if the actual login request asks
> for claims not already covered by this database record. The access
> token then "just" refers to the respective record for the particular
> user and client. If the end-user revokes the respective authorization
> (in our account management portal), the user info endpoint will refuse
> to provide user data any longer.
>
> regards,
> Torsten.
>
>
> Re: SCIM, current UserInfo endpoint schema lacks enterprise oriented
> claims. I was suggesting that perhaps we need them. OpenID Connect
> used to have the ability to specify the schema for userinfo endpoint,
> which was removed by https://bitbucket.org/openid/connect/issue/801/
> (It was resolved very quickly and the discussion is not recorded in
> the ticket so I cannot track the discussion easily for now). The
> reason we had "schema" parameter there was that we could state "scim"
> or "poco" there so that we can use the same access interface as
> userinfo while using different schema. That's what I was thinking of.
>
> 2013/5/3 Torsten Lodderstedt <torsten at lodderstedt.net
> <mailto:torsten at lodderstedt.net>>
>
> 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 <mailto: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
>     <mailto: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
>     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
>     <mailto:Openid-specs-ab at lists.openid.net>
>     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/20130504/f10560aa/attachment.html>