Hi Daniel, Kristina, Brian,
here are a few review comments that are easy to address:
1. Complete the IANA registry section for the media type registrations.
Search for TBD in that section. As you make this change you might also
want to remove the RFC 2119 language from the description fields. I do
not believe it is the right place to put normative language.
2. Normative Reference: I think you need to move RFC 8725, RFC5234, and
RFC6838 from the informative reference section to the normative section
since they are needed for the specification. RFC 8725 is probably a
reference we can argue about but the others seem to be pretty clear cases.
3. Minor nits:
In the introduction you write: "instead, a hash digest of the data takes
its place.". Since the digest is computed using a hash, it would be
better to just say "digest" instead of "hash digest". This would also be
consistent with the rest of the document.
In Section 4.1, you write: "The payload MUST NOT contain the reserved
claims _sd or ... except for the purpose of transporting digests as
described below.". The term "reserved claim" only appears once in the
document and it is not clear to me whether the "..." refers to the claim
with the name "..." or whether you are referring to the claims that this
document defines. The exception also appears misleading since you
defined the claims for conveying digests. The reference to "below" in
this sentence is not helping since I do not really know where to look at.
In Section 4.2.1, you write: "The claim value, as it would be used in a
regular JWT payload. The value MAY be of any type that is allowed in
JSON, including numbers, strings, booleans, arrays, null, and objects.".
I believe you should write "The value MUST be of a type that is allowed
in JSON....". The sentence appears more than once in the document.
In Section 9.1 you write: "The Issuer-signed JWT MUST be signed by the
Issuer to protect integrity of the issued claims.". I would remove the
first "Issuer-signed" qualification to improve the readability of the
sentence.
In Section 9.4, you write: "In the terminology of cryptographic
commitment schemes, the hash function MUST be computationally hiding.".
Since you mention the terminology, I expected a reference to the term,
especially given the use of RFC 2119 language.
Section 9.8 is called "Issuer Signature Key Distribution and Rotation".
It should instead be called "Issuer Signature Verification Key
Distribution" since you are not planning to distribute the signature key
of the issuer itself since it is the private key.
In Section 10.1, you write "The following types of unlinkability are
considered here:". I would change this to "The following types of
unlinkability are discussed below:"
I noticed the absence of a mention regarding the use of digital
signatures in Verifier/Verifier unlinkability. If a holder uses SD-JWTs
with different Verifiers, these SD-JWTs are linkable based on the
signature value, unless each SD-JWT is signed by the Issuer
individually. Batch issuance is suggested as a solution when the Holder
does not request SD-JWTs individually- either proactively or in
real-time. Proactively requesting SD-JWTs works in cases where the
holder knows in advance what disclosures the Verifier will ask for.
However, if there are many possible combinations, this approach may
become practically challenging. If the holder switches to a real-time
request pattern with the Issuer, the SD-JWT solution may become less
useful since the Holder can just ask the Issuer for a regular JWT that
only contains the claims it wants to disclose to the Verifier. Do the
existing media types support returning multiple SD-JWTs and multiple
SD-JWT+KBs in a batch?
In Section 11, you acknowledge Richard Barnes and Martin Thomson. I
suggest removing the "fnord" from Richard "fnord" Barnes and the
paragraph related to Martin Thomson:
"
Special appreciation is extended to Martin Thomson, who wielded his
considerable intellect and influence to change a single occurrence of
the word "to" to "with" in the midst of a significant proposal that
would be integrated into this document six months later.
"
I would also acknowledge Denis, even though his feedback was not
incorporated into the document. He certainly reviewed the document.
In the body of the document, you mention "credential" several times. It
might be helpful to clarify in the terminology section that this term is
a synonym for SD-JWT and SD-JWT+KB. In the appendix the term Verifiable
Credential is used a few times but in the body of the document you just
use the term "credential". I believe that "credential" and "Verifiable
Credential" are used interchangeably.
Ciao
Hannes
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
