Security News
Research
Data Theft Repackaged: A Case Study in Malicious Wrapper Packages on npm
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
This is the reference implementation of the IETF SD-JWT specification written in Python.
This implementation is used to generate the examples in the IETF SD-JWT specification and it can also be used in other projects for implementing SD-JWT.
To install this implementation, make sure that python3
and pip
(or pip3
) are available on your system and run the following command:
# create a virtual environment to install the dependencies
python3 -m venv venv
source venv/bin/activate
# install the latest version from git
pip install git+https://github.com/openwallet-foundation-labs/sd-jwt-python.git
This will install the sdjwt
python package and the sd-jwt-generate
script.
If you want to access the scripts in a new shell, it is required to activate the virtual environment:
source venv/bin/activate
The script sd-jwt-generate
is useful for generating test cases, as they might be used for doing interoperability tests with other SD-JWT implementations, and for generating examples in the SD-JWT specification and other documents.
For both use cases, the script expects a JSON file with settings (settings.yml
). Examples for these files can be found in the tests/testcases and examples directories.
Furthermore, the script expects, in its working directory, one subdirectory for each test case or example. In each such directory, there must be a file specification.yml
with the test case or example specifications. Examples for these files can be found in the subdirectories of the tests/testcases and examples directories, respectively.
The script outputs the following files in each test case or example directory:
sd_jwt_issuance.txt
: The issued SD-JWT. (*)sd_jwt_presentation.txt
: The presented SD-JWT. (*)disclosures.md
: The disclosures, formatted as markdown (only in 'example' mode).user_claims.json
: The user claims.sd_jwt_payload.json
: The payload of the SD-JWT.sd_jwt_jws_part.txt
: The serialized JWS component of the SD-JWT. (*)kb_jwt_payload.json
: The payload of the key binding JWT.kb_jwt_serialized.txt
: The serialized key binding JWT.verified_contents.json
: The verified contents of the SD-JWT.(*) Note: When JWS JSON Serialization is used, the file extensions of these files are .json
instead of .txt
.
To run the script, enter the respective directory and execute sd-jwt-generate
:
cd tests/testcases
sd-jwt-generate example
The specification.yml
file contains the test case or example specifications.
For examples, the file contains the 'input user data' (i.e., the payload that is
turned into an SD-JWT) and the holder disclosed claims (i.e., a description of
what data the holder wants to release). For test cases, an additional third
property is contained, which is the expected output of the verifier.
Implementers of SD-JWT libraries are advised to run at least the following tests:
In this library, the two tests are implemented in tests/test_e2e_testcases.py and tests/test_disclose_all_shortcut.py, respectively.
The specification.yml
file has the following format for test cases (find more examples in tests/testcases):
user_claims
user_claims
is a YAML dictionary with the user claims, i.e., the payload that
is to be turned into an SD-JWT. Object keys and array elements (and only
those!) can be marked for selective disclosure at any level in the data by
applying the YAML tag "!sd" to them.
This is an example of an object where two out of three keys are marked for selective disclosure:
user_claims:
is_over:
"13": True # not selectively disclosable - always visible to the verifier
!sd "18": False # selectively disclosable
!sd "21": False # selectively disclosable
The following shows an array with two elements, where both are marked for selective disclosure:
user_claims:
nationalities:
- !sd "DE"
- !sd "US"
The following shows an array with two elements that are both objects, one of which is marked for selective disclosure:
user_claims:
addresses:
- street: "123 Main St"
city: "Anytown"
state: "NY"
zip: "12345"
type: "main_address"
- !sd
street: "456 Main St"
city: "Anytown"
state: "NY"
zip: "12345"
type: "secondary_address"
The following shows an object that has only one claim (sd_array
) which is marked for selective disclosure. Note that within the array, there is no selective disclosure.
user_claims:
!sd sd_array:
- 32
- 23
holder_disclosed_claims
holder_disclosed_claims
is a YAML dictionary with the claims that the holder
discloses to the verifier. The structure must follow the structure of
user_claims
, but elements can be omitted. The following rules apply:
True
or yes
if the claim is disclosed and False
or no
if the claim
should not be disclosed.user_claims
. For each
value, if it is not False
or no
, the value is disclosed. If an array
element in user_claims
is an object or array, an object or array can be
provided here as well to describe which elements of that object/array should
be disclosed or not, if applicable.False
or no
. As above, if the value is an object or array, it is used
to describe which elements of that object/array should be disclosed or not,
if applicable.expect_verified_user_claims
Finally, expect_verified_user_claims
describes what the verifier is expected
to output after successfully consuming the presentation from the holder. In
other words, after applying holder_disclosed_claims
to user_claims
, the
result is expect_verified_user_claims
.
When key_binding
is set to true
, a Key Binding JWT will be generated.
Using serialization_format
, the serialization format of the SD-JWT can be
specified. The default is compact
, but json
is also supported.
FAQs
The reference implementation of the IETF SD-JWT specification.
We found that sd-jwt demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.