[OAUTH-WG] Re: SD-JWT architecture feedback

[Warren Parad <[e-mail]>]

+1

On Sat, Sep 21, 2024 at 6:44 AM Dick Hardt <[e-mail]> wrote:

> Hey Brian, Kristina, Daniel
>
> I appreciate you have been working on this for a while, and this feedback
> is last minute, and people have already working code that works with it --
> so this is unlikely to be welcome feedback -- but in the spirit of wanting
> what is best long term, here it is.
>
> *Token Separators*
> It is not clear to me why the disclosures are an arbitrary array of '~'
> separated items. It seems very odd to me as a developer. Why not have a 4th
> '.' separated string that is base64 URL encoded JSON array of the
> disclosures? The header includes the 'typ' so that a parser knows what all
> the following components are and how many there are.
>
> *Disclosure Format*
> On the format of the disclosures, the implicit semantics of the order of
> items in an array is a throwback to data formats of the last century. We
> are using JSON, let's have it be an object where we name each item.
>
> *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. Taking this out
> would simplify implementations.
>
> *Claim Names*
> Why do the claims start with '_'? Why not just 'sd' and 'sda'? Why is
> '_sd_alg' in the payload and not in the header?
>
> *Explicit Typing*
> Why leave the typing in the header to be determined by the application
> (10.11), and not just be 'sd-jwt' and be REQUIRED?
>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>