<div dir="auto">Ooohhhj now that's weird. All issuers know all about you.  That sux. Would that apply to getting a ticket to the hot chili peppers 🌶️ too.<br><br><div data-smartmail="gmail_signature">thx ..Tom (mobile)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 30, 2023, 10:19 AM David Chadwick <<a href="mailto:d.w.chadwick@truetrust.co.uk">d.w.chadwick@truetrust.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
    
  
  <div>
    <p><br>
    </p>
    <div>On 30/09/2023 14:26, Tom Jones wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">David, it sounds to me like the issuer is tracking
        the subject and inferring the subject's real world identity from
        the hints given in the request. Is that what you intended?</div>
    </blockquote>
    <p>On the contrary. The VC model is that the issuer already knows
      the subject and has a relationship with them. As a consequence,
      the subject (or more precisely the holder) is asking the issuer to
      issue a signed statement about the subject. Clearly the issuer is
      not going to sign a lie. And I would not expect an issuer to sign
      a statement that it has not validated is true (from its
      perspective - it could be wrong of course!).<br>
    </p>
    <p>Kind regards</p>
    <p>David<br>
    </p>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
          <div data-smartmail="gmail_signature" dir="auto">thx ..Tom
            (mobile)</div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sat, Sep 30, 2023, 3:14 AM
          David Chadwick via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" rel="noreferrer">openid-specs-ab@lists.openid.net</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div>
            <p>Using X.500 CAs as an example, if an erroneous request
              for a PKC is sent to the CA, the CA is entitled to correct
              the information and send back the correct information in
              the issued PKC. So if the issuer knows what the correct
              name of the VC subject is, it could return the VC with the
              correct name in the subject field. After all, the issuer
              is asserting the truth as it knows it to be. The holder
              can always reject the VC if it does not like the values
              that have been inserted by the issuer, but it cannot
              require the issuer to insert false values. There is no
              requirement on the holder to hold any VCs that it receives
              from the issuer or to present them to any verifier.</p>
            <p>Kind regards</p>
            <p>David<br>
            </p>
            <div>On 29/09/2023 16:07, Joseph Heenan via Openid-specs-ab
              wrote:<br>
            </div>
            <blockquote type="cite"> Hi Kai
              <div><br>
              </div>
              <div>I’m not sure any of these cases are really strictly
                defined. Certainly we don’t test any behaviours like
                this in any of the OpenID Foundation conformance tests,
                although the testing of the claims perhaps is certainly
                not comprehensive.</div>
              <div><br>
              </div>
              <div>Rejecting the request seems fine.</div>
              <div><br>
              </div>
              <div>Accepting the request but ignoring parts of it is
                probably acceptable as I can’t see anything that really
                defines the behaviour in this case. You should probably
                NOT return any claims where the request for that claim
                is invalid. The caveat would be that by ignoring that
                part of the request you’re also losing your ability to
                tell the developer why their request is not working as
                they expected, which makes it harder for them to figure
                out what they’ve done wrong and hence harder for them to
                fix their request to be valid.</div>
              <div><br>
              </div>
              <div>In reality we really shouldn’t be expecting a
                situation like this to occur except when a developer has
                badly misread the specification, and hence my instinct
                is we should err towards returning an error that tells
                the developer what they’ve done wrong.</div>
              <div><br>
              </div>
              <div>(For clarity the above is not an official position of
                the OpenID Foundation.)</div>
              <div><br>
              </div>
              <div>Thanks</div>
              <div><br>
              </div>
              <div>Joseph</div>
              <div><br>
                <div><br>
                  <blockquote type="cite">
                    <div>On 28 Sep 2023, at 14:06, Kai Lehmann via
                      Openid-specs-ab <a href="mailto:openid-specs-ab@lists.openid.net" rel="noreferrer noreferrer" target="_blank"><openid-specs-ab@lists.openid.net></a>
                      wrote:</div>
                    <br>
                    <div>
                      <div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Hi,</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> </span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">The OIDCC spec allows RPs to
                            request individual claims with the claims
                            parameter:</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> </span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"><a href="https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests" style="color:rgb(5,99,193);text-decoration:underline" rel="noreferrer noreferrer" target="_blank">https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests</a></span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> </span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">I was wondering how strict the
                            OP should be in handling invalid claim
                            values within this request. For example:</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> </span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">{</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">  “first_name”: “INVALID”,</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">  “last_name”: 5,</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">  “email”: {</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">    “essential”: “INVALID”</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">  }</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">}</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> </span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">My interpretation of “The
                            member values MUST be one of the following
                            …” would be that the claims request
                            parameter would be invalid if it contained
                            invalid member values and thus the server
                            should reject the request with a redirect
                            back to the RP’s provided redirect_uri with
                            invalid_request error. Would a more relaxed
                            parsing (ignoring invalid claim parameters)
                            also be an option and still in accordance
                            with the specification?</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> </span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Best regards,</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Kai</span></div>
                        <div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> </span></div>
                      </div>
                      <span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                      <span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">Openid-specs-ab
                        mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                      <a href="mailto:Openid-specs-ab@lists.openid.net" style="color:rgb(5,99,193);text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" rel="noreferrer noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
                      <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" style="color:rgb(5,99,193);text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a></div>
                  </blockquote>
                </div>
                <br>
              </div>
              <br>
              <fieldset></fieldset>
              <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
            </blockquote>
            <pre cols="72">-- 
IMPORTANT NOTICE

The email addresses ..@<a href="http://verifiablecredentials.info" rel="noreferrer noreferrer" target="_blank">verifiablecredentials.info</a> will shortly stop working. 
Can you please use

<a href="mailto:d.w.chadwick@truetrust.co.uk" rel="noreferrer noreferrer" target="_blank">d.w.chadwick@truetrust.co.uk</a>

from now on</pre>
          </div>
          _______________________________________________<br>
          Openid-specs-ab mailing list<br>
          <a href="mailto:Openid-specs-ab@lists.openid.net" rel="noreferrer noreferrer" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
          <a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
        </blockquote>
      </div>
    </blockquote>
  </div>

</blockquote></div>