[Openid-specs-ab] Handling of invalid claim values within claims request parameter

[Tom Jones]

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?

thx ..Tom (mobile)

On Sat, Sep 30, 2023, 3:14 AM David Chadwick via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> 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.
>
> Kind regards
>
> David
> On 29/09/2023 16:07, Joseph Heenan via Openid-specs-ab wrote:
>
> Hi Kai
>
> 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.
>
> Rejecting the request seems fine.
>
> 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.
>
> 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.
>
> (For clarity the above is not an official position of the OpenID
> Foundation.)
>
> Thanks
>
> Joseph
>
>
> On 28 Sep 2023, at 14:06, Kai Lehmann via Openid-specs-ab
> <openid-specs-ab at lists.openid.net> <openid-specs-ab at lists.openid.net>
> wrote:
>
> Hi,
>
> The OIDCC spec allows RPs to request individual claims with the claims
> parameter:
>
>
> https://openid.net/specs/openid-connect-core-1_0.html#IndividualClaimsRequests
>
> I was wondering how strict the OP should be in handling invalid claim
> values within this request. For example:
>
> {
>   “first_name”: “INVALID”,
>   “last_name”: 5,
>   “email”: {
>     “essential”: “INVALID”
>   }
> }
>
> 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?
>
> Best regards,
> Kai
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttps://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> --
> IMPORTANT NOTICE
>
> The email addresses .. at verifiablecredentials.info will shortly stop working.
> Can you please use
> d.w.chadwick at truetrust.co.uk
>
> from now on
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> https://lists.openid.net/mailman/listinfo/openid-specs-ab
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20230930/0e195374/attachment.html>