issues
search
oauth-wg
/
oauth-selective-disclosure-jwt
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
Other
57
stars
31
forks
source link
issues
Newest
Newest
Most commented
Recently updated
Oldest
Least commented
Least recently updated
SD-JWT Parser requires saving the base64 encoded values?
#532
samuelgoto
opened
1 week ago
0
Small (and optional) editorial SD-JWT+KB's spec suggestion: remove whitespace from examples of JSON serialization
#531
samuelgoto
opened
1 week ago
0
Missing procedures for Holder to validate disclosures received from Issuer
#530
rohanmahy
opened
1 week ago
1
Update of Issue #514 (new section 9.12) for the support of Post Quantum cryptography
#529
Denisthemalice
opened
2 weeks ago
0
Comments and issues raised during the 1rst and the 2nd WGLC have not been addressed in -14
#528
Denisthemalice
opened
2 weeks ago
0
Note that the Hash Function Claim value is case-sensitive
#525
bc-pi
closed
2 weeks ago
1
Update typ in SD-JWT VC example
#524
bc-pi
closed
2 weeks ago
0
Hash Function Claim value case-sensitivity
#523
spheroid
closed
2 weeks ago
6
The last paragraph of section 10.5 (Issuer Identifier) can be removed
#522
Denisthemalice
closed
2 weeks ago
0
A new section about "Issuer anonymity" should be added
#521
Denisthemalice
closed
2 weeks ago
0
Section 10.3 (Confidentiality during Transport) should also mention integrity
#520
Denisthemalice
closed
2 weeks ago
0
Since claims always contain privacy-sensitive data section 10.2 would need to be reworded
#519
Denisthemalice
closed
2 weeks ago
0
Holders SHOULD NOT be required to store SD-JWTs "only in encrypted form"
#518
Denisthemalice
closed
2 weeks ago
0
Section 10.2 should be made more general to consider both the storage of signed and un-signed data
#517
Denisthemalice
closed
2 weeks ago
0
A new section about "End-User intrackability" should be added
#516
Denisthemalice
closed
2 weeks ago
1
The term "unlinkability" is overloaded. For more clarity, the wording "End-user intrackability" should be used in addition
#515
Denisthemalice
closed
2 weeks ago
0
A section should be added to consider the case of a presentation of claims to Verifier that have been issued by different Issuers
#514
Denisthemalice
closed
2 weeks ago
0
Section 9.5 (Key Binding) needs to be revised to consider the case of a collusion between End-Users
#513
Denisthemalice
closed
2 weeks ago
0
Section 7.3 needs to be revised to describe which data structures can be transmitted
#512
Denisthemalice
closed
2 weeks ago
0
The requirement for an Issuer of not providing a SD-JWT+KB-JWT should be removed
#511
Denisthemalice
closed
2 weeks ago
0
Verification steps for the KB-JWT are missing in section 7.1
#510
Denisthemalice
closed
2 weeks ago
0
Validation steps for the KB-JWT are missing
#509
Denisthemalice
closed
2 weeks ago
0
The iat time at which the Key Binding JWT was issued should not be REQUIRED
#508
Denisthemalice
closed
2 weeks ago
0
It is important to mention the use of decoy digests and of the shuffling of the digests included in the SD-JWT payload
#507
Denisthemalice
closed
2 weeks ago
0
How the Holder key pair is established cannot be placed "out of the scope of this document"
#506
Denisthemalice
closed
2 weeks ago
0
Add an example of using arrays for "age_over" and "age_under" claims
#505
Denisthemalice
closed
2 weeks ago
0
It would be worth to mention that the Issuer decides which claims are always disclosed
#504
Denisthemalice
closed
2 weeks ago
0
The description of the SD-JWT+KB is confusing
#503
Denisthemalice
closed
2 weeks ago
1
The description of the SD-JWT can be improved
#502
Denisthemalice
closed
2 weeks ago
0
The benefits of the nonce and of the audience value can be made more accurate
#501
Denisthemalice
closed
2 weeks ago
0
The data elements sent to the Verifier are not correctly defined
#500
Denisthemalice
closed
2 weeks ago
0
The format used to carry both the SD-JWT and the Disclosures is unclear
#499
Denisthemalice
closed
2 weeks ago
0
Figure 1 should be corrected to take into account the existence of an End-user and to consider KB-JWT instead of KB
#498
Denisthemalice
closed
2 weeks ago
0
The term End-User should be added to the definitions
#497
Denisthemalice
closed
2 weeks ago
0
The definition of a Verifier would need to be reworded
#496
Denisthemalice
closed
2 weeks ago
0
The definition of an Holder would need to be reworded
#495
Denisthemalice
closed
2 weeks ago
0
The definition of an Issuer would need to be reworded
#494
Denisthemalice
closed
2 weeks ago
0
The definition of a "key binding JWT" would need to be reworded
#493
Denisthemalice
closed
2 weeks ago
0
The definition of "key binding" would need to be reworded
#492
Denisthemalice
closed
2 weeks ago
0
The definition of the Selectively Disclosable JWT (SD-JWT) would need to be reworded
#491
Denisthemalice
closed
2 weeks ago
0
The definition of the SD-JWT+KB structure needs to be reworded
#490
Denisthemalice
closed
2 weeks ago
0
A (KB-JWT) does not demonstrate a "proof of possession" of private key
#489
Denisthemalice
closed
2 weeks ago
2
What is a "facility for associating an SD-JWT with a key pair" ?
#488
Denisthemalice
closed
2 weeks ago
0
Difference between "a format extending the JWS Compact Serialization" and "an alternate format extending the JWS JSON Serialization" ?
#487
Denisthemalice
closed
2 weeks ago
0
The structure called "SD-JWT+KB" should be renamed "SD-JWT+KB-JWT"
#486
Denisthemalice
closed
2 weeks ago
0
Key binding will be ineffective unless the SD-JWT includes an additional claim that indicates the Holder characteristics: "hcahr"
#485
Denisthemalice
closed
2 weeks ago
0
A Holder does not present a "JWT" to a Verifier but "SD-JWT + Sel.Claims"
#484
Denisthemalice
closed
2 weeks ago
0
Indicate that "claims" refers either to object properties (name/value pairs) and to array elements
#483
Denisthemalice
closed
2 weeks ago
0
Make a difference between the Holder which is an *application* and the individual (i.e. End-User)
#482
Denisthemalice
closed
2 weeks ago
0
Address Denis' comments
#481
danielfett
closed
2 weeks ago
1
Next