<div dir="ltr">"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. <div>
<br></div><div>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 <a href="https://bitbucket.org/openid/connect/issue/801/">https://bitbucket.org/openid/connect/issue/801/</a> (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. </div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/3 Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi Nat,<br>
<br>
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.<br>

<br>
Regarding SCIM: are you saying openid connect is inappropriate for enterprise scenarios?<br>
<br>
regards,<br>
Torsten.<br><br><div class="gmail_quote"><br>
<br>
Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> schrieb:<div><div class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<p style="margin:0px;padding:0px;word-wrap:break-word"><font><span style="line-height:normal;background-color:rgba(255,255,255,0)">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.</span></font></p>

<p style="margin:10px 0px;padding:0px;word-wrap:break-word"><font><span style="line-height:normal;background-color:rgba(255,255,255,0)">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.<span></span></span></font></p>

<p style="margin:10px 0px;padding:0px;word-wrap:break-word"><font><span style="line-height:normal;background-color:rgba(255,255,255,0)">Nat</span></font></p><br>2013年5月2日木曜日 Torsten Lodderstedt <a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
please take a look at <a href="https://bitbucket.org/openid/connect/issue/832/standard-41-add-claim-filter-to-user-info" target="_blank">https://bitbucket.org/openid/<u></u>connect/issue/832/standard-41-<u></u>add-claim-filter-to-user-info</a> and give your feedback.<br>


<br>
I think the way to control the claim set returned by the user info endpoint needs some clarification/improvement.<br>
<br>
regards,<br>
Torsten.<br>
<br>
------------------------------<u></u>----------------------------<br>
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.<br>


<br>
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).<br>


<br>
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.<br>
______________________________<u></u>_________________<br>
Openid-specs-ab mailing list<br>
<a>Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/<u></u>mailman/listinfo/openid-specs-<u></u>ab</a><br>
</blockquote><br></blockquote></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>