<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"MS PGothic";
        panose-1:2 11 6 0 7 2 5 8 2 4;}
@font-face
        {font-family:"\@MS PGothic";
        panose-1:2 11 6 0 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"MS PGothic","sans-serif";
        color:black;
        mso-fareast-language:JA;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"MS PGothic","sans-serif";
        color:black;
        mso-fareast-language:JA;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Torsten,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Please consider implementing what the working group suggested when it decided not to take action in this regard now.  That is:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span lang="EN" style="font-size:10.5pt;font-family:"Arial","sans-serif";color:#333333">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.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">                                                            -- Mike<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-bounces@lists.openid.net]
<b>On Behalf Of </b>Torsten Lodderstedt<br>
<b>Sent:</b> Saturday, May 04, 2013 4:52 AM<br>
<b>To:</b> Nat Sakimura<br>
<b>Cc:</b> openid-specs-ab@lists.openid.net<br>
<b>Subject:</b> Re: [Openid-specs-ab] Add claim filter to user info request<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Nat,<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 04.05.2013 07:38, schrieb Nat Sakimura:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">"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.
<o:p></o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><br>
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. <br>
<br>
As a general note: <br>
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).
<br>
<br>
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. <br>
<br>
Treating the authorization request and the attribute query as the same has some unpleasant implications.
<br>
<br>
1) The client has to perform additional OpenID requests in order to change the user info response.
<br>
 a) request to end-user authorization endpoint with changed claim set<br>
 b) exchange auth code id and access token<br>
 c) access user info endpoint (if data are not transfered in id token) <br>
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.<br>
<br>
2) the OP has to maintain transactional state with every code, access and refresh token, resulting in a more complex and less scalable implementation.<br>
<br>
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.
<br>
<br>
regards,<br>
Torsten.<br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">2013/5/3 Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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.<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> schrieb:
<o:p></o:p></p>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p style="margin:0in;margin-bottom:.0001pt;word-wrap:break-word">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.<o:p></o:p></p>
<p style="mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;margin-left:0in;word-wrap:break-word">
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.<o:p></o:p></p>
<p style="mso-margin-top-alt:7.5pt;margin-right:0in;margin-bottom:7.5pt;margin-left:0in;word-wrap:break-word">
Nat<o:p></o:p></p>
<p class="MsoNormal"><br>
2013<span lang="JA">年</span>5<span lang="JA">月</span>2<span lang="JA">日木曜日</span> Torsten Lodderstedt
<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>:<o:p></o:p></p>
<p class="MsoNormal">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/connect/issue/832/standard-41-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>
----------------------------------------------------------<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>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">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/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
Nat Sakimura (=nat) <o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>