arXiv:2607.09370v1 [cs.CR] 10 Jul 2026
SFDS: Selective File Disclosure System Aditya Mitra
Quazi Fariha Tasnim
Hristina Mihajloska Trpcheska
CyberMACS Kadir Has University Istanbul, Turkey [email protected] ORCiD: 0000-0002-9612-0810
CyberMACS Kadir Has University Istanbul, Turkey [email protected]
Faculty of Computer Science and Engineering Ss. Cyril and Methodius University Skopje, North Macedonia [email protected]
Abstract—Access control to networked resources has been a longstanding challenge. The conventional solution relies on authentication mechanisms, which introduce additional complexities associated with Identity and Access Management (IAM). Such systems require user authentication, identity management, and authorization services, while also introducing security risks arising from vulnerabilities, misconfigurations, or implementation flaws. Furthermore, different file formats employ different mechanisms for ensuring authenticity and integrity through digital signatures. For example, PDF documents support the PDF Advanced Electronic Signature (PAdES) standard, whereas plain text files typically lack a standardized mechanism for embedding digital signatures. This paper proposes an architecture based on the Selective Disclosure JSON Web Token (SD-JWT) standard for securely sharing read-only files. The proposed architecture embeds cryptographic signatures and integrity protection directly into the shared resource, providing verifiable authenticity without relying on complex IAM infrastructures, such as centralized user databases, authentication services, or authorization mechanisms. By eliminating these components, the proposed solution simplifies deployment while maintaining strong security guarantees for the distribution of immutable resources. Index Terms—privacy, decentralize, JWT, SD-JWT, Verifiable credentials
I. I NTRODUCTION In many scenarios read-only files are shared but an extensive access control system is used for the process. This involves the use of databases, authentication systems, and authorization lists, followed by extensively securing the authentication systems. But even, once the files are downloaded by the user, proving the integrity of the file and the source requires a whole separate infrastructure for digital signatures. This scenario is often seen in educational institutions, where they often need to maintain authentication systems for the student grade sheets, ensuring one student cannot access that of another. However, the transcripts still need to be digitally signed, requiring one more digital signature infrastructure and signing the transcript of each student individually. Another appropriate example would be the medical industry where maintaining the integrity and confidentiality of patient data is very important. However, access control of such Personal Health Information (PHI) often involves creating robust authentication and authorization systems [1]. Further, maintaining the integrity and authenticity of such data is paramount for proper treatment of the patients. However, most
medical reports are generated using legacy medical machines which do not cryptographic digital signatures and integrity checking mechanisms. Further, the file formats used by such legacy machines do not support such digital signature or other methods of maintaining integrity and authenticity. This study proposes a system to simplify these problems, leveraging the SD-JWT standard [2] for sharing such information. It ensures only the authorized holders holding the Verifiable Presentation corresponding to the information may only be able to access the contents of the information, and at the same time provide authenticity and integrity from the issuer. The contributions in this study include: • Development of an architecture to share files over SDJWT and Verifiable Credentials standard. • Ensure interoperability with SD-JWT and Verifiable Presentations. • Ensure the Verifiable Presentations required to access the files are small enough to be transferred over limited bandwidth or stored on devices with limited storage or other formats like QR Codes. • Ensure the integrity of the files shared this way is maintained and is verifiable. II. L ITERATURE R EVIEW Access control and digital signature to big files irrespective of their types is important in modern internet. While modern file types like PDFs have signature standards like PAdES [3], legacy file formats often lack digital signature and integrity mechanisms. There have been multiple studies highlighting problems regarding privacy and integrity of legacy standards like text, images, etc. A study [4] highlights fine-grained access control of multimedia content with caching in network. Another study [5] highlights the challenges on Big Data access control schemes. On the other hand, the SD-JWT standard [2] along with W3C Verifiable Credentials [6] gives a promising standard for securely disclosing claims which are verifiable cryptographically. Claims can be represented as read only values, usually a string or number and often represents the credential of the user. For example, identity cards, driving license, student records, etc., can all be represented in the form of verifiable credentials model. Most ID documents are, in fact, stored and
shared as verifiable credentials as per the eIDAS (electronic Identification, Authentication and Trust Services) regulation under the European Union [7] [8]. The SD-JWT standard has been instrumental in maintaining the privacy of Verifiable Credentials. It allows a presenter to reveal only a part of the verifiable credential with he needs to prove to the verifier while keeping the rest of it a secret. It has been instrumental in preserving privacy of the credentials while at the same time being able to use only the ones required. [9] [10]. One of the major problems with the verifiable credential model, is that the claims used in the same are almost always only string or numbers. This brings in a bigger hurdle when it is needed to share big files, usually binary files in a verifiable manner. One of the easier solutions could have been encoding the files to Base64 and use that as a string value, analogous to standard Verifiable credentials. However, it would eventually bloat up the presentations and make it difficult to share them over media that offers very little space, like QR codes or smart cards. One of the main ideas of SD-JWT based credentials, accompanying physical cards is being presentable by the card only, and it often boils down to QR codes and NFC only. [11] [12]. On the other hand, often authentication and access management are involved with privately sharing files. This involves authentication by standard factors like knowledge based, possession based or inherence based [13]. This requires complex architecture involving databases, authentication systems, and so on. The files are often shared on cloud, IPFS etc., without a standard for selective disclosure. [14] [15]. The proposed Selective File Disclosure System outlines a procedure to privately share files in a private manner where the content of the file remains verifiable. Table I highlights the advantages of SFDS over traditional methods. III. M ETHODOLOGY The proposed architecture involves three actors: the issuer, the presenter and the verifier. The issuer is the source of the data and ensures the authenticity of the data. On the other hand, the presenter or the holder is the entity that receives the data from the issuer and may hold it for future use. The verifier is the entity requiring proof of the data. This follows the W3C Verifiable Credential Data Model, ensuring all claims are verifiable cryptographically. This proposed system expands on the Verifiable Credential and SD-JWT models to ensure the same can be expanded to bigger files, instead of smaller claims that can fit in one single JSON file. It further streamlines the issuance for multiple files together. For example, an educational institute may create one JSON file containing the transcripts of all students and share the respective presentations to the students who may use it to read their transcripts and at the same time share it with potential verifiers like recruiters, who may verify the validity and read the transcript. The system also ensures these transcripts can be issued in human-readable formats like PDF or scanned copies like JPEG instead of only machine-readable JSON. This ensures the shared information may retain non-text information as well, for example scanned
TABLE I C OMPARISON OF SFDS WITH E XISTING A PPROACHES
Feature
SFDS
File Sharing with Standard IAM
SD-JWT
Use of Blockchain or distributed file system like IPFS
Big file sharing capability
Yes
Yes
No
Yes
Privacy preserving architecture
Yes
Yes
Yes
Partial
Simplicity of architecture
Yes
No
Yes
No
Requires complex moving parts like databases
No
Yes
No
No
Revocability
Yes
Yes
Partial: revoked records only hamper the verifiability, not the content
Partial: depends on implementation
Limited storage: Can big files be presented on limited storage media
Yes
Yes (or no storage media required if memorized secrets are used for authentication)
No (if files are shared in presentations)
Partial: depends on implementation
records of student answer scripts. Figure 1 demonstrates the structure of a SFDS record. A. Issuer flow The issuer is the entity that produces the files and is responsible for maintaining authenticity. The issuer creates the JSON Web Token containing the information of the files, as well as the presentation that grants the holder permission to view the files and verify its authenticity. The issuer iterates through the directory containing the files to share. A cryptographic hash of the file is generated. It generates a random symmetric cryptographic key for each file and uses AES in Galois Counter Mode with 256-bit key size to encrypt each file separately. While the current implementation of the system uses AES-GCM, other implementations may use other symmetric cryptographic algorithms as well that provide strong security, based on the speed and performance requirements. The ’Alg’ field in the JWT identifies the used algorithm by its COSE identifier. AES-GCM provides confidentiality and ciphertext integrity through its AEAD authentication tag. The plaintext hash included in the SD-JWT disclosure provides an additional issuer-authenticated content binding and enables verification that the decrypted file corresponds to the issuer’s intended file. Therefore, the AEAD tag and the plaintext hash
Header
Hash 1
Hash 2
Hash 3
Encrypted File 1
Encrypted File 2
Hash
File Name and path
Salt
Hash
File Name and path
Salt
Hash
Offset
Salt
File Name and path
Length
Offset
Offset
Key
Length
Length
Hash
Key
Presentation 1
Hash
Key
Hash
Presentation 2
Presentation 3
Blob URI
Encrypted File 3
Signature: JWS
Fig. 1. SFDS Structure
serve complementary purposes and both must be verified. The encrypted file is appended to a binary large object (Blob). The offset at which the encrypted file is appended, and the length of the encrypted file are recorded. The disclosure is made which contains the file name, the offset, the length of the encrypted file, the encryption key, hash of the original file and a random salt. These disclosures are hashed and added to the JWT. The Blob created this way may contain random padding between two encrypted files, before all files or at the end to reduce chances of inference-based attacks. The blob could be hosted on a web platform or a decentralized platform and the URI to access it is added to the JWT. The JWT is then signed by the issuer key to create the JWS which is appended to the end. The issuer may then share the JWT and the respective disclosures with the authorized holders. The flow of the issuer may be represented in algorithm 1. When the issuer has to revoke a file, apart from standard revocability procedures outlined in W3C Verifiable Credentials model, the issuer may replace the corresponding bytes in the blob with random data to ensure it cannot be retrieved and decrypted, without breaking the integrity of other files in the blob. B. Presenter flow The presenter is the authorized holder of the disclosures and may present it to verifiers. If the presenter attempts to view the content of the file referred to in the disclosure, the presenter will follow the verifier flow. The presenter may decide which files to disclose to the verifier, followed by creating a verifiable presentation in accordance with the W3C VC Model. The presenter flow may be represented in Algorithm 2. 1) Verifier flow: The verifier is the entity that holds the presentation and is able to read the content of the files referred to by them. The verifier validates the verifiable presentation,
Algorithm 1 Issuer Workflow (Issuerpub , Issuerpriv ) ← K EY G EN(ECDSA) Blob ← ∅ SDList ← ∅ Disclosures ← ∅ for all files in the directory and its subdirectories do (F ileN ame, F ile) ← R EAD F ILE() Hash ← SHA256(F ile) Key ← R ANDOM K EY() N once ← R ANDOM N ONCE() (Cipher, T ag) ← AES-GCM-256 E NCRYPT(F ile, Key, N once) EncryptedF ile ← Cipher ∥ N once ∥ T ag Of f set ← L ENGTH(Blob) Length ← L ENGTH(EncryptedF ile) Alg ← 3 ▷ COSE identifier for AES-GCM-256 F ileData ← {F ileN ame, Key, Hash, Of f set, Length, Alg} Blob ← Blob ∥ EncryptedF ile Salt ← R ANDOM S ALT() SDList ← SDList ∪ {SHA256(Salt ∥ F ileData)} Disclosures ← Disclosures ∪ {Salt ∥ F ileData} end for BlobU RI ← URI(Blob) Content ← Header ∥ SDList ∥ BlobU RI JW T ← Content ∥ S IGN(Content, Issuerpriv ) return (Issuerpub , JW T, Disclosures)
followed by extracting the presentation list from it. The verifier also validates the JWT with the public key of the issuer. This is followed by the verifier checking whether the hashes of the disclosures in the presentation are in the JWT to ensure the disclosures are valid. This is followed by the verifier extracting the key, hash, offset and length from the disclosures. The verifier then fetches
Algorithm 2 Presenter Workflow Disclosures ← disclosures received from issuer P resentationList ← ∅ for all Disclosure ∈ Disclosures do F ileData ← E XTRACT F ILE DATA(Disclosure) F ileN ame ← E XTRACT F ILE NAME(F ileData) Prompt user whether to disclose F ileN ame if user chooses to disclose then P resentationList ← P resentationList ∪ {Disclosure} end if end for return P resentationList
the part of the blob from the offset to the desired length. If it is shared on web, the Range header [16] [17] may be used to get only the desired part of the blob. The part of the blob is then decrypted using the key. A hash of the decrypted blob is verified against the hash in the disclosure to ensure it is the intended file. This is followed by writing the file to the verifier disk as per the file name in the disclosure. The verifier may then be able to read the file and be assured of the integrity and authenticity of the file. The flow of the verifier might be represented by Algorithm 3.
The blob storage and share are an added dependency to SFDS compared to W3C Verifiable Credentials. The threat model of the blob storage share includes: Unauthorized access. The blob storage is open to access without permission. Unauthorized access to the same reveals nothing because all data is encrypted. • Inference attacks. Malicious actors may try to infer information by studying metadata like the blob storage size. To mitigate the same issuer may add random padding between two encrypted files or before and after files. This padding, being random, should be statistically not differentiable from the encrypted data, thus mitigating inference-based attacks. Further, the use of Decoy Disclosures in accordance with [2] ensures inference attacks from the number of hashes present in the JWT is mitigated. •
The security goals of the shared files are maintained by: Confidentiality. The disclosure is required to decrypt the file. Without the disclosure, the files remain confidential. • Integrity. The JWT is signed with the private key of the issuer. The validity of the signature ensures the integrity of the JWT. The integrity of the presentations is validated by comparing the cryptographic hash of the same with that on the JWT. The integrity of the files shared over SFDS is validated by comparing the hash of the file against the one in the presentations. Thus, integrity is established in a transitive way. • Availability. Even if the Blob URI faces attacks related to availability, the presenter may separately supply file to the verifier, and the verifier would still be able to validate the authenticity and integrity of the file. •
Algorithm 3 Verifier Workflow P resentationList ← received from presenter (Issuerpub , JW T ) ← received from issuer (Content, Signature) ← E XTRACT JWT(JW T ) V ERIFY S IGNATURE(Signature, Content, Issuerpub ) (SDList, BlobU RI) ← E XTRACT C ONTENT(Content) for all P resentation ∈ P resentationList do V. E XPERIMENTAL SETUP Verify SHA256(P resentation) ∈ SDList F ileData ← E XTRACT F ILE DATA(P resentation) The proposed system has been implemented in python and (F ileN ame, Key, Hash, tested. Three independent computers were used as issuer, Of f set, Length, Alg) ← PARSE(F ileData) holder and verifier respectively. The issuer’s public key was EncryptedF ile ← available to the verifier, and the presenter supplied the preF ETCH(BlobU RI, Of f set, Of f set + Length) sentation. In the experimental scenario, the issuer shared a Cipher, N once, T ag ← U NPACK(EncryptedF ile) folder with multiple multimedia, text and executable files. F ile ← The presenter chose the files to be disclosed and created the AES-GCM-256 D ECRYPT(Cipher, Key, N once, T ag) presentation. The Verifier was able to recreate the shared files Verify SHA256(F ile) = Hash and verify the signature to validate the integrity. The issuer W RITE F ILE(F ileN ame, F ile) was then able to use the shared files. end for This study does not include a performance study of the proposed standard since it is highly dependent on the implementation. Figure 2 shows the JWT generated by the impleIV. T HREAT MODEL mentation. The token contains disclosure digest placeholders The threat model of the proposed SFDS architecture en- under the files array and a blob reference used to retrieve the compasses the threat model of W3C Verifiable Credential data encrypted bundle. Figure 3 shows the SD-JWT presentation model. The contribution of this study adds sharing big binary produced by the holder, consisting of the issuer-signed JWT files and Binary large objects over the verifiable credential followed by selected Base64 URL-encoded disclosures sepamodel. This expands it to support non-text data which in- rated by ASCII tilde characters. cludes items like raw medical records produced by medical The Python-based implementation and the test vectors for equipment. this study is available at [18].
a2dRIiwgeyJwYXRoIjogImV4YW1wbGVcXHN1YmRcXHRlc3QzLnR4 dCIsICJvZmZzZXQiOiA3MiwgImxlbmd0aCI6IDM1LCAiaGFzaCI6 ICJBWXhub3NNTzJaZC1IZDMtbU1yRlFoWmRyRFZjLVhaTWthTmlZ VDUxS1RNIiwgImtleSI6ICJoeHVLVF9wQTBQZjllMXo2a2p0eS00 ekFMSjVLZGh0bU5YbG93VlJJUTY0IiwgImFsZyI6IDN9XQ˜
Listing 3. SD-JWT presentation containing selected disclosures Fig. 2. JWT generated by implementation
[’avy3ozSTqLZDMLlUHQI8jQ’, {’path’: ’example\\test1.txt’, ’offset’: 0, ’length’: 36, ’hash’: ’hwKmdFRN69WkkKB 9ZeFmDnbwc5yzxu9J0vxI2I-KQro’, ’key’: ’RvPUIIaLLZ2Oa jh0f5EmxqzkTv1hffiTDLzeZmD3lNE’, ’alg’: 3}] [’lWhihnN-FDe0VtLGEm4a8g’, {’path’: ’example\\test2.txt’, ’offset’: 36, ’length’: 36, ’hash’: ’jPrDtbgHl5dyFY eRzCbrHjjR0WiSuGFKF5InAz-BI8g’, ’key’: ’JLhRPpAGl0tU 3aSCcK0_Ep2-1OLlmeG3k2OxtbGXRsU’, ’alg’: 3}]
Fig. 3. Disclosures
VI. RFC 9901 COMPLIANCE AND V ERIFIER R ECONSTRUCTION This section highlights the test vectors and outputs from the sample implementation. eyJhbGciOiAiRVMyNTYiLCAidHlwIjogImV4YW1wbGUrc2Qtand0In0.e yJmaWxlcyI6IFt7Ii4uLiI6ICJEWHBTenViQmtTMWRIYmNxYVVUN m9WVVY4SFZBbXlZdXd6T3BlT00tbXhvIn0sIHsiLi4uIjogIkVFW m1aTGtyMXpONTc2Rjk0OUQ2RnBIcnc2Y25PQ04wU3BxMXY1NmVZb U0ifSwgeyIuLi4iOiAiOFEtOHVjb3Z5X05QZnNfVklWYzQ5MlgyY WVXRC1OU1dtczZkV3dicV9VVSJ9XSwgImJsb2IiOiAiZGF0YTphc HBsaWNhdGlvbi9vY3RldC1zdHJlYW07YmFzZTY0LFhWQzFaRHZhQ ndBd2Eza01HSWtrOERsX24zdk9rQzJUdVNqdGwtYURQVTJJQ2dJR U5YVnlJRlFjNzVEMV80V3RaVWExZGdVR3N6TEJ6Q0p1X0NhSENvV DJDR3ZsODNKVkJMQzVPMldfUzJuTjRJNlNVLS1wSVAzaExwNVBXN jB3TGVTOVo0cTNmcEEyMk5FPSIsICJfc2RfYWxnIjogInNoYS0yN TYifQ.4tSNrDAPBPZWYWurQw5k0pB1M5RXvXZukrkqtWYKf_Y1Hi gkbIbPNEqynordiV4Bqk44btZDFIf9GV_gDFxYOA
Listing 1. Issuer signed JWT in compact serialization { "files": [ { "...": "DXpSzubBkS1dHbcqaUT6oVUV8HV AmyYuwzOpeOM-mxo" }, { "...": "EEZmZLkr1zN576F949D6FpHrw6c nOCN0Spq1v56eYmM" }, { "...": "8Q-8ucovy_NPfs_VIVc492X2aeWD-NSWms6 dWwbq_UU" } ], "blob": "data:application/octet-stream;base64,X VC1ZDvaBwAwa3kMGIkk8Dl_n3vOkC2TuSjtl-aDPU2ICgIENXVyI FQc75D1_4WtZUa1dgUGszLBzCJu_CaHCoT2CGvl83JVBLC5O2W_S 2nN4I6SU--pIP3hLp5PW60wLeS9Z4q3fpA22NE=", "_sd_alg": "sha-256" }
Listing 2. Decoded Issuer-signed JWT Payload ˜WyJhdnkzb3pTVHFMWkRNTGxVSFFJOGpRIiwgeyJwYXRoIjogImV4YW1w bGVcXHRlc3QxLnR4dCIsICJvZmZzZXQiOiAwLCAibGVuZ3RoIjog MzYsICJoYXNoIjogImh3S21kRlJONjlXa2tLQjlaZUZtRG5id2M1 eXp4dTlKMHZ4STJJLUtRcm8iLCAia2V5IjogIlJ2UFVJSWFMTFoy T2FqaDBmNUVteHF6a1R2MWhmZmlUREx6ZVptRDNsTkUiLCAiYWxn IjogM31d˜WyJsV2hpaG5OLUZEZTBWdExHRW00YThnIiwgeyJwYXR oIjogImV4YW1wbGVcXHRlc3QyLnR4dCIsICJvZmZzZXQiOiAzNiw gImxlbmd0aCI6IDM2LCAiaGFzaCI6ICJqUHJEdGJnSGw1ZHlGWWV SekNickhqalIwV2lTdUdGS0Y1SW5Bei1CSThnIiwgImtleSI6ICJ KTGhSUHBBR2wwdFUzYVNDY0swX0VwMi0xT0xsbWVHM2syT3h0Ykd YUnNVIiwgImFsZyI6IDN9XQ˜WyJ5RGFZWFpOc3Q4LS1BdDJxLW5o
[’yDaYXZNst8--At2q-nhkgQ’, {’path’: ’example\\subd\\test3 .txt’, ’offset’: 72, ’length’: 35, ’hash’: ’AYxnosMO 2Zd-Hd3-mMrFQhZdrDVc-XZMkaNiYT51KTM’, ’key’: ’hxuKT_ pA0Pf9e1z6kjty-4zALJ5KdhtmNXlowVRIQ64’, ’alg’: 3}]
Listing 4. Decoded disclosures
Verifier reconstruction The issuer creates the signed payload as represented in listing 1 and the disclosure list as in listing 3. The disclosure digests in the payload are created by hashing the Base64 Encoded disclosures as shown in listing 3. The listings 1, 2, 3, and 4 shows compliance with the SD-JWT standard as defined in [2]. The verifier extracts the JWS signature from the JWT payload and validates the same with the issuer public key. For each disclosure, the verifier computes BASE64URL(SHA256(ASCII(Disclosure)), where Disclosure is the Base64Url encoded disclosure string from Listing 3. The resulting digest is compared with the corresponding digest placeholder in the issuer-signed JWT Payload. Once they are validated, the disclosures are Base64Url decoded to retrieve the metadata required to reconstruct the file, and the verifier inspects the offset and length fields of the same. The verifier then extracts the corresponding segment marked by the offset and length from the Blob. It then decrypts and extracts the nonce and AEAD tag from the section. It uses the AES key in disclosure to decrypt the encrypted file and validates the AEAD tag. A hash of the decrypted file is calculated and validated against the hash in the disclosure payload. It finally inspects the file name and file types from the path metadata field in the disclosure and writes the file to the disk for usage. VII. T EST V ECTORS This section highlights the test vectors from the sample implementation that can be used to reproduce the study. File 1: Path: example\test1.txt Plaintext content: test1 Plaintest SHA-256 hash (URL Safe B64 Encoded): hwKmdF RN69WkkKB9ZeFmDnbwc5yzxu9J0vxI2I-KQro File 2: Path: example\test2.txt Plaintext content: test2 Plaintest SHA-256 hash (URL Safe B64 Encoded): jPrDtb gHl5dyFYeRzCbrHjjR0WiSuGFKF5InAz-BI8g
File 3: Path: example\subd\test3.txt Plaintext content: test3 Plaintest SHA-256 hash (URL Safe B64 Encoded): AYxnos MO2Zd-Hd3-mMrFQhZdrDVc-XZMkaNiYT51KTM
Listing 5. Input files Signing algorithm: ES256 Issuer pulic key (COSE Encoded): { "crv": "P-256", "kty": "EC", "x": "Ie9X6X9D2m8Oh3k1WXmyJNR_aZpROb7DDpDBstFc9yQ", "y": "QFQmYn0jObNveUyUbXnrIuKVfjbUac88J7P1AWc9yoM" } Issuer private key (COSE Encoded): { "crv": "P-256", "d": "NyXgWlmQ-PzWi0dzOBWC168MTPXXt0R98Q3AAtnroQI", "kty": "EC", "x": "Ie9X6X9D2m8Oh3k1WXmyJNR_aZpROb7DDpDBstFc9yQ", "y": "QFQmYn0jObNveUyUbXnrIuKVfjbUac88J7P1AWc9yoM" } _sd_alg value: sha256
AEAD tag: zpAtk7ko7Zfmgz1NiAoCBA Offset: 0 Length: 36 File 2: AES Key: JLhRPpAGl0tU3aSCcK0_Ep2-1OLlmeG3k2OxtbGXRsU Nonce: 9f-FrWVGtXYFBrMy Ciphertext: NXVyIFQc75A AEAD tag: wcwibvwmhwqE9ghr5fNyVQ Offset: 36 Length: 36 File 3: AES Key: AYxnosMO2Zd-Hd3-mMrFQhZdrDVc-XZMkaNiYT51KTM Nonce: ac3gjpJT76kg_eEu Ciphertext: BLC5O2W_Sw AEAD tag: nk9brTAt5L1nird-kDbY0Q Offset: 72 Length: 35 Blob: data:application/octet-stream;base64,XVC1ZDvaBwAwa3 kMGIkk8Dl_n3vOkC2TuSjtl-aDPU2ICgIENXVyIFQc75D1_4WtZU a1dgUGszLBzCJu_CaHCoT2CGvl83JVBLC5O2W_S2nN4I6SU--pIP 3hLp5PW60wLeS9Z4q3fpA22NE=
Listing 8. Encryption data
Listing 6. Issuer Parameters
Expected outputs File 1: Salt: avy3ozSTqLZDMLlUHQI8jQ File descriptor before encoding: {’path’: ’example\\t est1.txt’, ’offset’: 0, ’length’: 36, ’hash’: ’hwKmd FRN69WkkKB9ZeFmDnbwc5yzxu9J0vxI2I-KQro’, ’key’: ’RvP UIIaLLZ2Oajh0f5EmxqzkTv1hffiTDLzeZmD3lNE’, ’alg’: 3} Base64URL encoded disclosure: WyJhdnkzb3pTVHFMWkRNTGx VSFFJOGpRIiwgeyJwYXRoIjogImV4YW1wbGVcXHRlc3QxLnR4dCI sICJvZmZzZXQiOiAwLCAibGVuZ3RoIjogMzYsICJoYXNoIjogImh 3S21kRlJONjlXa2tLQjlaZUZtRG5id2M1eXp4dTlKMHZ4STJJLUt Rcm8iLCAia2V5IjogIlJ2UFVJSWFMTFoyT2FqaDBmNUVteHF6a1R 2MWhmZmlUREx6ZVptRDNsTkUiLCAiYWxnIjogM31d Disclosure digest: DXpSzubBkS1dHbcqaUT6oVUV8HVAmyYuwz OpeOM-mxo File 2: Salt: lWhihnN-FDe0VtLGEm4a8g File descriptor before encoding: {’path’: ’example\\t est2.txt’, ’offset’: 36, ’length’: 36, ’hash’: ’jPrD tbgHl5dyFYeRzCbrHjjR0WiSuGFKF5InAz-BI8g’, ’key’: ’JL hRPpAGl0tU3aSCcK0_Ep2-1OLlmeG3k2OxtbGXRsU’, ’alg’: 3 } Base64URL encoded disclosure: WyJsV2hpaG5OLUZEZTBWdEx HRW00YThnIiwgeyJwYXRoIjogImV4YW1wbGVcXHRlc3QyLnR4dCI sICJvZmZzZXQiOiAzNiwgImxlbmd0aCI6IDM2LCAiaGFzaCI6ICJ qUHJEdGJnSGw1ZHlGWWVSekNickhqalIwV2lTdUdGS0Y1SW5Bei1 CSThnIiwgImtleSI6ICJKTGhSUHBBR2wwdFUzYVNDY0swX0VwMi0 xT0xsbWVHM2syT3h0YkdYUnNVIiwgImFsZyI6IDN9XQ Disclosure digest: EEZmZLkr1zN576F949D6FpHrw6cnOCN0Sp q1v56eYmM File 3: Salt: yDaYXZNst8--At2q-nhkgQ File descriptor before encoding: {’path’: ’example\\s ubd\\test3.txt’, ’offset’: 72, ’length’: 35, ’hash’: ’AYxnosMO2Zd-Hd3-mMrFQhZdrDVc-XZMkaNiYT51KTM’, ’key ’: ’hxuKT_pA0Pf9e1z6kjty-4zALJ5KdhtmNXlowVRIQ64’, ’a lg’: 3} Base64URL encoded disclosure: WyJ5RGFZWFpOc3Q4LS1BdDJ xLW5oa2dRIiwgeyJwYXRoIjogImV4YW1wbGVcXHN1YmRcXHRlc3Q zLnR4dCIsICJvZmZzZXQiOiA3MiwgImxlbmd0aCI6IDM1LCAiaGF zaCI6ICJBWXhub3NNTzJaZC1IZDMtbU1yRlFoWmRyRFZjLVhaTWt hTmlZVDUxS1RNIiwgImtleSI6ICJoeHVLVF9wQTBQZjllMXo2a2p 0eS00ekFMSjVLZGh0bU5YbG93VlJJUTY0IiwgImFsZyI6IDN9XQ Disclosure digest: 8Q-8ucovy_NPfs_VIVc492X2aeWD-NSWms 6dWwbq_UU
Listing 7. Per file disclosure data File 1: AES Key: RvPUIIaLLZ2Oajh0f5EmxqzkTv1hffiTDLzeZmD3lNE Nonce: MGt5DBiJJPA5f597 Ciphertext: XVC1ZDvaBwA
{ "files": [ { "...": "DXpSzubBkS1dHbcqaUT6oVUV8HVAmyYuwzOpeOM-mxo " }, { "...": "EEZmZLkr1zN576F949D6FpHrw6cnOCN0Spq1v56eYmM " }, { "...": "8Q-8ucovy_NPfs_VIVc492X2aeWD-NSWms6dWwbq_UU " } ], "blob": "data:application/octet-stream;base64,XVC1ZDvaB wAwa3kMGIkk8Dl_n3vOkC2TuSjtl-aDPU2ICgIENXVyIFQc75D1_ 4WtZUa1dgUGszLBzCJu_CaHCoT2CGvl83JVBLC5O2W_S2nN4I6SU --pIP3hLp5PW60wLeS9Z4q3fpA22NE=", "_sd_alg": "sha-256" }
Listing 9. Decoded JWT Payload Compact issuer-signed JWT: eyJhbGciOiAiRVMyNTYiLCAidHlwIj ogImV4YW1wbGUrc2Qtand0In0.eyJmaWxlcyI6IFt7Ii4uLiI6IC JEWHBTenViQmtTMWRIYmNxYVVUNm9WVVY4SFZBbXlZdXd6T3BlT0 0tbXhvIn0sIHsiLi4uIjogIkVFWm1aTGtyMXpONTc2Rjk0OUQ2Rn BIcnc2Y25PQ04wU3BxMXY1NmVZbU0ifSwgeyIuLi4iOiAiOFEtOH Vjb3Z5X05QZnNfVklWYzQ5MlgyYWVXRC1OU1dtczZkV3dicV9VVS J9XSwgImJsb2IiOiAiZGF0YTphcHBsaWNhdGlvbi9vY3RldC1zdH JlYW07YmFzZTY0LFhWQzFaRHZhQndBd2Eza01HSWtrOERsX24zdk 9rQzJUdVNqdGwtYURQVTJJQ2dJRU5YVnlJRlFjNzVEMV80V3RaVW ExZGdVR3N6TEJ6Q0p1X0NhSENvVDJDR3ZsODNKVkJMQzVPMldfUz JuTjRJNlNVLS1wSVAzaExwNVBXNjB3TGVTOVo0cTNmcEEyMk5FPS IsICJfc2RfYWxnIjogInNoYS0yNTYifQ.4tSNrDAPBPZWYWurQw5 k0pB1M5RXvXZukrkqtWYKf_Y1HigkbIbPNEqynordiV4Bqk44btZ DFIf9GV_gDFxYOA Final SD-JWT presentation: eyJhbGciOiAiRVMyNTYiLCAidHlwIj ogImV4YW1wbGUrc2Qtand0In0.eyJmaWxlcyI6IFt7Ii4uLiI6IC JEWHBTenViQmtTMWRIYmNxYVVUNm9WVVY4SFZBbXlZdXd6T3BlT0 0tbXhvIn0sIHsiLi4uIjogIkVFWm1aTGtyMXpONTc2Rjk0OUQ2Rn BIcnc2Y25PQ04wU3BxMXY1NmVZbU0ifSwgeyIuLi4iOiAiOFEtOH Vjb3Z5X05QZnNfVklWYzQ5MlgyYWVXRC1OU1dtczZkV3dicV9VVS J9XSwgImJsb2IiOiAiZGF0YTphcHBsaWNhdGlvbi9vY3RldC1zdH JlYW07YmFzZTY0LFhWQzFaRHZhQndBd2Eza01HSWtrOERsX24zdk 9rQzJUdVNqdGwtYURQVTJJQ2dJRU5YVnlJRlFjNzVEMV80V3RaVW ExZGdVR3N6TEJ6Q0p1X0NhSENvVDJDR3ZsODNKVkJMQzVPMldfUz JuTjRJNlNVLS1wSVAzaExwNVBXNjB3TGVTOVo0cTNmcEEyMk5FPS IsICJfc2RfYWxnIjogInNoYS0yNTYifQ.4tSNrDAPBPZWYWurQw5 k0pB1M5RXvXZukrkqtWYKf_Y1HigkbIbPNEqynordiV4Bqk44btZ
DFIf9GV_gDFxYOA˜WyJhdnkzb3pTVHFMWkRNTGxVSFFJOGpRIiwg eyJwYXRoIjogImV4YW1wbGVcXHRlc3QxLnR4dCIsICJvZmZzZXQi OiAwLCAibGVuZ3RoIjogMzYsICJoYXNoIjogImh3S21kRlJONjlX a2tLQjlaZUZtRG5id2M1eXp4dTlKMHZ4STJJLUtRcm8iLCAia2V5 IjogIlJ2UFVJSWFMTFoyT2FqaDBmNUVteHF6a1R2MWhmZmlUREx6 ZVptRDNsTkUiLCAiYWxnIjogM31d˜WyJsV2hpaG5OLUZEZTBWdEx HRW00YThnIiwgeyJwYXRoIjogImV4YW1wbGVcXHRlc3QyLnR4dCI sICJvZmZzZXQiOiAzNiwgImxlbmd0aCI6IDM2LCAiaGFzaCI6ICJ qUHJEdGJnSGw1ZHlGWWVSekNickhqalIwV2lTdUdGS0Y1SW5Bei1 CSThnIiwgImtleSI6ICJKTGhSUHBBR2wwdFUzYVNDY0swX0VwMi0 xT0xsbWVHM2syT3h0YkdYUnNVIiwgImFsZyI6IDN9XQ˜WyJ5RGFZ WFpOc3Q4LS1BdDJxLW5oa2dRIiwgeyJwYXRoIjogImV4YW1wbGVc XHN1YmRcXHRlc3QzLnR4dCIsICJvZmZzZXQiOiA3MiwgImxlbmd0 aCI6IDM1LCAiaGFzaCI6ICJBWXhub3NNTzJaZC1IZDMtbU1yRlFo WmRyRFZjLVhaTWthTmlZVDUxS1RNIiwgImtleSI6ICJoeHVLVF9w QTBQZjllMXo2a2p0eS00ekFMSjVLZGh0bU5YbG93VlJJUTY0Iiwg ImFsZyI6IDN9XQ˜ Selected Disclosures: ˜WyJhdnkzb3pTVHFMWkRNTGxVSFFJOGpRIi wgeyJwYXRoIjogImV4YW1wbGVcXHRlc3QxLnR4dCIsICJvZmZzZX QiOiAwLCAibGVuZ3RoIjogMzYsICJoYXNoIjogImh3S21kRlJONj lXa2tLQjlaZUZtRG5id2M1eXp4dTlKMHZ4STJJLUtRcm8iLCAia2 V5IjogIlJ2UFVJSWFMTFoyT2FqaDBmNUVteHF6a1R2MWhmZmlURE x6ZVptRDNsTkUiLCAiYWxnIjogM31d˜WyJsV2hpaG5OLUZEZTBWd ExHRW00YThnIiwgeyJwYXRoIjogImV4YW1wbGVcXHRlc3QyLnR4d CIsICJvZmZzZXQiOiAzNiwgImxlbmd0aCI6IDM2LCAiaGFzaCI6I CJqUHJEdGJnSGw1ZHlGWWVSekNickhqalIwV2lTdUdGS0Y1SW5Be i1CSThnIiwgImtleSI6ICJKTGhSUHBBR2wwdFUzYVNDY0swX0VwM i0xT0xsbWVHM2syT3h0YkdYUnNVIiwgImFsZyI6IDN9XQ˜WyJ5RG FZWFpOc3Q4LS1BdDJxLW5oa2dRIiwgeyJwYXRoIjogImV4YW1wbG VcXHN1YmRcXHRlc3QzLnR4dCIsICJvZmZzZXQiOiA3MiwgImxlbm d0aCI6IDM1LCAiaGFzaCI6ICJBWXhub3NNTzJaZC1IZDMtbU1yRl FoWmRyRFZjLVhaTWthTmlZVDUxS1RNIiwgImtleSI6ICJoeHVLVF 9wQTBQZjllMXo2a2p0eS00ekFMSjVLZGh0bU5YbG93VlJJUTY0Ii wgImFsZyI6IDN9XQ˜
Listing 10. Issuer signed JWT and Final presentation File 1: hwKmdFRN69WkkKB9ZeFmDnbwc5yzxu9J0vxI2I-KQro File 2: jPrDtbgHl5dyFYeRzCbrHjjR0WiSuGFKF5InAz-BI8g File 3: AYxnosMO2Zd-Hd3-mMrFQhZdrDVc-XZMkaNiYT51KTM
Listing 11. Reconstructed file hashes
The listings 5 to 11 represent the test vectors which can be used to reproduce the study. VIII. C ONCLUSION The proposed Selective File Disclosure System aims at solving the problem of verifiable file disclosure in a privacyfocused manner. It ensures only the authorized holders of the presentations and disclosures can view the contents of respective files without involving complex architectures like authentication systems, user databases, Identity and Access Management, etc. A few notable use cases of SFDS might be: • Education. Students often need to share verifiable copies of their transcripts, exam scripts and so on. Current SDJWT standards may be used to share verifiable copies of the transcript where the data are represented in a machinereadable format, but not the entire scanned copies of the transcript or exam scripts. SFDS is a promising solution to the problem. • Medicine. Like the problem of education, medicine demands the authenticity and integrity of health information. Current SD-JWT standards offer sharing medical reports, containing medical conditions, values of various tests, and diagnoses in machine-readable formats. However, it does not support sharing raw reports like Xray plates, images captured by MRI or Ultrasonography machines, etc. Further, these machines are often legacy
and do not support digital signatures on the produced files. The SFDS aims to solve these and related problems. ACKNOWLEDGMENT This research was conducted within the framework of the Erasmus Mundus Joint Master’s Programme in Applied Cybersecurity (CyberMACS) Project No. 101082683, co-funded by the European Union under the Erasmus+ MUNDUS Programme. R EFERENCES [1] F. Quazi, A. Khanna, S. Nalluri, and N. Gorrepati, “Data security & privacy in healthcare,” International Journal of Global Innovations and Solutions (IJGIS), Jul. 2024. [2] D. Fett, K. Yasuda, and B. Campbell, “Selective Disclosure for JSON Web Tokens,” RFC 9901, Nov. 2025. [Online]. Available: https://www.rfc-editor.org/info/rfc9901 [3] N. Pope, “Protecting long term validity of PDF documents with PAdESLTV,” in ISSE 2009 Securing Electronic Business Processes. Wiesbaden: Vieweg+Teubner, 2010, pp. 320–327. [4] P. He, K. Xue, J. Yang, Q. Xia, J. Liu, and D. S. L. Wei, “FASE: Finegrained accountable and space-efficient access control for multimedia content with in-network caching,” IEEE Trans. Netw. Serv. Manag., vol. 18, no. 4, pp. 4462–4475, Dec. 2021. [5] K. Yang, Q. Han, H. Li, K. Zheng, Z. Su, and X. Shen, “An efficient and fine-grained big data access control scheme with privacy-preserving policy,” IEEE Internet Things J., vol. 4, no. 2, pp. 563–571, Apr. 2017. [6] M. Sporny, D. Longley, D. Chadwick, C. Lemmer-Webber, and T. Looker, “Verifiable credentials data model v2.0,” World Wide Web Consortium (W3C), W3C Recommendation, May 2024. [Online]. Available: https://www.w3.org/TR/vc-data-model-2.0/ [7] A. Sharif, M. Ranzi, R. Carbone, G. Sciarretta, F. A. Marino, and S. Ranise, “The eIDAS regulation: A survey of technological trends for european electronic identity schemes,” Appl. Sci. (Basel), vol. 12, no. 24, p. 12679, Dec. 2022. [8] J. Inza, “The european digital identity wallet as defined in the EIDAS 2 regulation,” in Law, Governance and Technology Series. Cham: Springer Nature Switzerland, 2025, pp. 433–452. [9] A. D. Salve, A. Lisi, M. Cascino, P. Mori, and L. Ricci, “Selective disclosure approaches in self-sovereign identity: An experimental comparison,” IEEE Access, vol. 14, pp. 1152–1181, 2026. [10] A. P. Perez and L. E. Vidal, “Decentralized identity management,” in Holistic Iot Security, Privacy and Safety: Integrated, Approaches Protecting a Highly Connected World, K. Loupos, Ed. Emerald Publishing Limited, 05 2025. [Online]. Available: https://doi.org/10.1561/978-1-63828-507-620251006 [11] R. V. Brăcăcescu, Ş. Mocanu, A. D. Ioniţă, and C. Brăcăcescu, “A proposal of digital identity management using blockchain,” Rev. Roum. Sci. Tech., vol. 69, no. 1, pp. 85–90, Apr. 2024. [12] A. Abid, S. Cheikhrouhou, S. Kallel, and M. Jmaiel, “NovidChain: Blockchain-based privacy-preserving platform for COVID-19 test/vaccine certificates,” Softw. Pract. Exp., vol. 52, no. 4, pp. 841–867, Apr. 2022. [13] P. A. Grassi, J. L. Fenton, E. M. Newton, R. A. Perlner, A. R. Regenscheid, W. E. Burr, J. P. Richer, N. B. Lefkovitz, J. M. Danker, Y.-Y. Choong, K. K. Greene, and M. F. Theofanos, “Digital identity guidelines: authentication and lifecycle management,” Gaithersburg, MD, Tech. Rep., Jun. 2017. [14] P. Ambre, S. Bane, A. Singh, S. Sharma, and M. Patekar, “Turtl: IPFS based decentralized file sharing system,” in 2023 3rd International Conference on Pervasive Computing and Social Networking (ICPCSN). IEEE, Jun. 2023, pp. 1533–1537. [15] X. Luo, Y. Ren, J. Hu, Q. Wu, and J. Lou, “Privacy-preserving identitybased file sharing in smart city,” Pers. Ubiquitous Comput., vol. 21, no. 5, pp. 923–936, Oct. 2017. [16] R. T. Fielding, Y. Lafon, and J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Range Requests,” RFC 7233, Jun. 2014. [Online]. Available: https://www.rfc-editor.org/info/rfc7233 [17] R. T. Fielding, M. Nottingham, and J. Reschke, “HTTP Semantics,” RFC 9110, Jun. 2022. [Online]. Available: https://www.rfceditor.org/info/rfc9110
[18] A. Mitra, “SFDS: Selective file disclosure system,” https://github.com/AdityaMitra5102/SFDS, 2026, accessed: July 13, 2026.