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

[Tom Jones]

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.

thx ..Tom (mobile)

On Sat, Sep 30, 2023, 10:19 AM David Chadwick <d.w.chadwick at truetrust.co.uk>
wrote:

>
> On 30/09/2023 14:26, Tom Jones wrote:
>
> 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?
>
> 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!).
>
> Kind regards
>
> David
>
>
> 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/04d4690f/attachment-0001.html>