<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>