Hi Dick,
Am 21.09.24 um 06:41 schrieb Dick Hardt:
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.
You are unfortunately correct - not only have we been working on this
for a while now, we also discussed many of the points you list below
already. Since not all of those discussions happened here on the mailing
list, I'll link to the relevant Github issues where appropriate.
*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.
If you use a JSON array for the disclosures, you need to
double-base64-url-encode all disclosures, needlessly increasing the size
of the SD-JWT(-KB). Please read these issues:
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/36
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/180
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/37
*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.
We had that in the beginning, but the consensus was that we don't want
to increase the size by using named object properties. Short
single-letter properties were considered as well, but didn't add much
value over an array.
*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. 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).
Taking this out would simplify implementations.
Fluff -- are there features that, when removed, would not 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?
While the underscore doesn't officially have any special meaning, adding
it reduces the chance for collisions with existing claims and makes the
SD-JWT-related claims sort nicely. All SD-related claims are in the
payload, that's why we put _sd_alg there as well.
*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?
We had extensive discussions around typing, please refer to the
following issues:
- https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/267
- https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/327
- https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/345
-Daniel
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
