<html>
<head>
<meta content="text/html; charset=ISO-2022-JP"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Mike,<br>
<br>
we will do this and share our experiences with the working group.<br>
<br>
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.<br>
<br>
regards,<br>
Torsten. <br>
<br>
<br>
Am 04.05.2013 19:33, schrieb Mike Jones:<br>
</div>
<blockquote
cite="mid:4E1F6AAD24975D4BA5B16804296739436770EDB4@TK5EX14MBXC283.redmond.corp.microsoft.com"
type="cite">
<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]-->
<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
style="font-size:10.5pt;font-family:"Arial","sans-serif";color:#333333"
lang="EN">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">
<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>
[<a class="moz-txt-link-freetext" href="mailto:openid-specs-ab-bounces@lists.openid.net">mailto:openid-specs-ab-bounces@lists.openid.net</a>]
<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> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" 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>
</blockquote>
<br>
</body>
</html>