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 -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
