Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add directives for payload sizes #437

Open
PatStLouis opened this issue Dec 10, 2024 · 1 comment
Open

Add directives for payload sizes #437

PatStLouis opened this issue Dec 10, 2024 · 1 comment
Assignees
Labels
ready for PR Issue ready to be resolved via a Pull Request

Comments

@PatStLouis
Copy link
Collaborator

Some credentials are very large, especially when they contain inline svg data. There should be some guidance around this as I've noticed some vc-api implementations are currently returning a failed verification because of a payload exceeding the server's limit. This is also affecting the security of the server and may be part of the instance configuration.

@msporny
Copy link
Contributor

msporny commented Jan 7, 2025

This was discussed during the 2025-01-07 telecon:

@PatStLouis was trying to verify VCs that were large (5MB+), trying to verify with available VC API implementations and few returned error information on payload size too large. Images embedded in VCs (preferred way to do it security-wise), disadvantage is that the size of the payload is too large to process. Is there an alternative way to manage this issue? @dlongley noted that reasonable defaults might be the way to go... VCs might need to be less than 10MBs -- document storage systems have 16MB storage limits, for example. It might not be best practice to include images in VCs inline -- benefit for not fetching external requests, but could be mitigated via links w/ hashes, or where image isn't needed, or fetched or provided through privacy-preserving means. Probably not a good idea to make VCs large when they can't be selectively disclosed. @PatStLouis noted that for proximity use cases, file size is a concern. @dlongley noted that multiple VCs in a presentation could result in 30MB-50MB presentations, changes for denial of service, keeping VCs small is good, but can also lead to privacy concerns. @PatStLouis noted that content authenticity is of interest -- capture modifications that have been made. @dlongley noted work having VCs for images themselves, that might be something better leveraged for that use case.

A PR should be raised that explains the effects of VC sizes on implementations (DoS possibility and interop issues w/ large VCs), and a default maximum VC size of 10MB to ensure that there is a baseline interoperability (with the option for implementations to allow larger sizes if configured to do so). The note should also note that database limits should be taken into consideration like the 16MB limit for most document-based storage solutions. By default, large binary values should be linked to and a hash included (unless there is a privacy reason for not doing so). The note should also mention that VC size limits should be set at an instance-level.

@msporny msporny added the ready for PR Issue ready to be resolved via a Pull Request label Jan 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready for PR Issue ready to be resolved via a Pull Request
Projects
None yet
Development

No branches or pull requests

2 participants