<html>
<head>
<meta content="text/html; charset=ISO-2022-JP"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Nat,<br>
<br>
<div class="moz-cite-prefix">Am 04.05.2013 07:38, schrieb Nat
Sakimura:<br>
</div>
<blockquote
cite="mid:CABzCy2Dqpgy3rbSTEWMdj3odL3cbg4z=ZrW9SicX==rGxZoqfw@mail.gmail.com"
type="cite">
<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. <br>
</div>
</blockquote>
<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>
<blockquote
cite="mid:CABzCy2Dqpgy3rbSTEWMdj3odL3cbg4z=ZrW9SicX==rGxZoqfw@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
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. </div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2013/5/3 Torsten Lodderstedt <span
dir="ltr"><<a moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
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">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><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 moz-do-not-send="true" href="http://nat.sakimura.org/"
target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en</div>
</div>
</blockquote>
<br>
</body>
</html>