Mixed-type arrays

[alenhorvat]

Dear,

thank you for the great work!

I have a question about the design-rational behind the "Disclosures for array elements" (https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-12.html#name-disclosures-for-array-eleme)

The current design transforms arrays into mixed-type arrays (which is compatible with JSON format), but it is causing parsing inconveniences in some languages; Example: a credential has a claim which is a single-type array, e.g., array of strings. If SD-JWT is applied, the claim type must be changed into an interface and when parsed, type checking is performed to detect hidden claims.

An alternative might be ["claim-name.3", "value"] (and put into _sd as key-value claims) or by introducing explicit types ["array-element", "array-claim-name", "position", "value"] (and put into _sd as key-value claims)

there would be 2 types:

• 0: key-value
• 1: array-element and enum can be used to minimise the size

Thank you for your time and answers!

[danielfett]

Hi Alen,

I agree that the current form is not ideal for parsing, especially in strongly typed languages. However, we did consider the approaches similar to the ones you propose when designing the array feature, but we decided against it in the end. If I remember correctly, the reasons were:

• It is not clear how that would work with nested arrays. Admittedly, that might be a super-rare use case. But with the current option, we can confidently say that we can selectively disclose any element in a JWT payload, independent of its type or where it is nested.
• Related, the mental model behind the current approach aligns with what we have for the key/value disclosures: You find the digest where the original element would be; not a level higher. I found this much easier to implement, as it works nicely with a simple recursion; when processing the array, I don't need any "outside" information.
• I found it slightly harder to describe all potential pitfalls and problems when parsing the structure you propose, e.g.: What if a claim name already exists as an object? What if a number is given twice?

None of these are a really "hard" reason to do it they way we do today; but neither is the typing problem a reason not to do it.

[alenhorvat]

Dear Daniel,

Thank you for your answer.

Yes, with nested array the syntax basically boils down to JSON pointers which were already discussed. I missed the nested arrays.

None of these are a really "hard" reason to do it they way we do today; but neither is the typing problem a reason not to do it.

I agree and it's your design decision. Due to nested arrays is either as is or pointers.

The issue can be closed.

Thank you for your answers and time.