<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Helvetica, Arial, sans-serif">Agreed it's a different
      container... but to me the semantics of the container matter. The
      software statement is likely signed by a third party while the
      registration parameters (while maybe signed) are kind of "self
      asserted". As an AS, what I really need to know is "who" is making
      the request and then base the entitled claims on that more so than
      what's presented.<br>
      <br>
      Would you want to delegate to a partner the ability for them to
      specify which claims their clients can obtain without any
      "oversight" from the AS perspective?<br>
      <br>
      Thanks,<br>
      George<br>
    </font><br>
    <div class="moz-cite-prefix">On 8/12/15 2:37 PM, Torsten Lodderstedt
      wrote:<br>
    </div>
    <blockquote cite="mid:55CB924E.8020104@lodderstedt.net" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      I don't distinguish claims in the registration request and in the
      software statement. It's just a different "container".<br>
      <br>
      <div class="moz-cite-prefix">Am 12.08.2015 um 20:32 schrieb George
        Fletcher:<br>
      </div>
      <blockquote cite="mid:55CB913F.5010102@aol.com" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        <font face="Helvetica, Arial, sans-serif">If these are claims
          the RP is entitled to receive, how does the AS verify that
          claim? Shouldn't that data be in the Software Statement rather
          than in the client reg parameters? I'm probably missing
          something :)<br>
          <br>
          Thanks,<br>
          George<br>
        </font><br>
        <div class="moz-cite-prefix">On 8/12/15 2:19 PM, Torsten
          Lodderstedt wrote:<br>
        </div>
        <blockquote cite="mid:55CB8E3C.9020106@lodderstedt.net"
          type="cite">good point. I would assume this is the list of
          claims the RP is entitled to get access to. I think it doesn't
          matter whether the RP asks for the claim via scopes or claims
          parameter. <br>
          <br>
          Entitlement is given by the authority, which issued the
          software statement, the RP wants to register with. <br>
          <br>
          Am 12.08.2015 um 01:07 schrieb John Bradley: <br>
          <blockquote type="cite">So these wold be default claims, or a
            filter that prevents more than the listed claims from coming
            back. <br>
            <br>
            How do you see this interacting with scopes? <br>
            <br>
            <br>
            <blockquote type="cite">On Aug 11, 2015, at 8:32 AM, Torsten
              Lodderstedt <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:torsten@lodderstedt.net"><torsten@lodderstedt.net></a>
              wrote: <br>
              <br>
              Hi Mike, <br>
              <br>
              as you are in the process of producing eratas of the OIDC
              specs, I would like to raise a question regarding client
              registration we came up with in the MODRNA WG. Right now,
              the RP may restrict itself to certain grant and response
              types. We see the need to do the same for claims. Would
              you consider it a reasonable enhancement of the Client
              Registration spec to add something like "claims" to the
              registration spec? I consider it complementary to
              "claims_supported" as specified in the discovery spec. <br>
              <br>
              kind regards, <br>
              Torsten. <br>
              <br>
              <br>
              _______________________________________________ <br>
              Openid-specs-ab mailing list <br>
              <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
                href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
              <br>
              <a moz-do-not-send="true" class="moz-txt-link-freetext"
                href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
              <br>
            </blockquote>
          </blockquote>
          <br>
          _______________________________________________ <br>
          Openid-specs-ab mailing list <br>
          <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
            href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
          <br>
          <a moz-do-not-send="true" class="moz-txt-link-freetext"
            href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
          <br>
          <br>
        </blockquote>
        <br>
        <div class="moz-signature">-- <br>
          <a moz-do-not-send="true" href="http://connect.me/gffletch"
            title="View full card on Connect.Me"><img
              moz-do-not-send="true"
              src="cid:part1.09020401.04090500@aol.com" alt="George
              Fletcher" height="113" width="359"></a></div>
      </blockquote>
      <br>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      <a href="http://connect.me/gffletch" title="View full card on
        Connect.Me"><img src="cid:part8.03050408.03030008@aol.com"
          alt="George Fletcher" height="113" width="359"></a></div>
  </body>
</html>