You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.
The text was updated successfully, but these errors were encountered: