Hi Dick,
I am going to comment only about your array item disclosure points among
your topics from this post.
I also originally questioned why disclosing individual items in an array
was necessary and proposed an alternate syntax. While I didn't have a use
case as an implementer back then, I have since stumbled on one that turns
out to be reasonably elegant.
It is not merely necessary to be able to express the disclosures, but also
to place the digests where they belong in the "redacted" version of the
JWT. To do that in an array you need to be able to distinguish an
unredacted item from a digest. Lots of systems use SHA256 hashes as
identifiers. If I had an array of IM groups that the Holder was authorized
to administer, where each group is represented by 44 base64url characters,
it would be indistinguishable from a selective disclosure digest using the
default algorithm. Using a map with a single "..." key makes it easy to
distinguish that using a key name that is unlikely to accidentally appear
in the wild.
```
"admin_of_groups: [
"cDFj1yd1dcAnhXmgD4N8A5ndOaoz9OVJVyqFfSJn9_U",
"HpdMwEDlFCpvNvo9CxflnHRAFr1sLY0SEpK68FM2eJ0"
]
```
vs.
```
"admin_of_groups: [
"cDFj1yd1dcAnhXmgD4N8A5ndOaoz9OVJVyqFfSJn9_U",
{"...": "HpdMwEDlFCpvNvo9CxflnHRAFr1sLY0SEpK68FM2eJ0"}
]
```
Finally, it was certainly more work to implement array items in SD-JWT and
SD-CWT, but it was much less than twice the work.
Thanks,
-rohan
On Sat, Sep 21, 2024 at 9:16 AM Dick Hardt <dick.ha...@gmail.com> wrote:
>
>
> On Sat, Sep 21, 2024 at 4:28 PM Daniel Fett <m...@danielfett.de> wrote:
>
>> Hi Dick,
>> Am 21.09.24 um 06:41 schrieb Dick Hardt:
>>
>> *Array Disclosure*
>> Is this really needed? The only example I saw was for multiple
>> citizenships. Would the issuer of an SD-JWT that contains a subject's
>> citizenship not be the country who they are a citizen of? Why would another
>> country be authoritative that the subject is a citizen of another country?
>> In the example, it is hard to imagine a verifier trusting the US to say
>> someone is a DE citizen, or vice versa. The array of age claims in example
>> A.3 does not need the non intuitive '...' array mechanism.
>>
> Yes, it is needed. First of all, SD-JWT can be used universally, not just
>> for credentials.
>>
> I don't know what that sentence means. It is alluded to in the current
> introduction, and makes no sense to me. Are you saying that an SD-JWT could
> be used to selectively disclose claims that are not user identity claims?
> Sure.
>
>> Second, even if used for credentials, there are many types of credentials
>> where there is a use case for disclosing only some array values. Take an
>> education credential as an example, where the holder may want to disclose
>> only relevant courses and grades. You'll find more use cases in the
>> examples in the appendix.
>>
>> A bit besides the point, but in the EU context we do in fact plan for
>> credentials attesting other nationalities (and have good reasons to do so,
>> here PID credentials derived from the eID card for EU citizens, see
>> https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/functions/00-pid-issuance-and-presentation/#pid-contents
>> for details).
>>
> I'm going to dig in on this point. SD-JWT is NOT taking a JSON array as
> input. You have an array of digests and an array of disclosures. You can
> have as many of the same property as you want like you are doing with the
> age claims in the example.
>
> IE you can have a digests for "nationality"="DE" and for
> "nationality"="US" and then have a disclosure for each one. No '...' magic
> needed.
>
>
>
>> Taking this out would simplify implementations.
>>
>> Fluff -- are there features that, when removed, would not simplify
>> implementations?
>>
>
> I'll restate it more strongly, I think the array support will double the
> effort for no real benefit since as noted above, you can already include
> multiples of the same property in an SD-JWT
>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
