Re: VC size and re-directs

On Tue, Oct 11, 2022 at 7:06 AM David Chadwick
<david.chadwick@crosswordcybersecurity.com> wrote:
> One of the OIDC4VCs protocols has a redirect in it

Is this part of the NGI Atlantic profile?

> The former flow may not work with VCs with embedded images, but the later flow will work with any size of VP and embedded VC.

Let's please not add solutions that require one to know browser
limitations on URL sizes. Not all browsers have the same limitations:

https://www.geeksforgeeks.org/maximum-length-of-a-url-in-different-browsers/

Most notably, Microsoft Edge has a limit of 2083 characters, which is
less than the size of many VCs that we deal with (that are not encoded
in CBOR-LD).

> - should VCs with embedded images be of a (slightly) different type and schema to the equivalent VC with a URL pointing to the image, so that they can be differentiated between?

No, because in this case, it's backwards. The limitations of a
protocol (like OIDC) based on the restrictions of a browser shouldn't
impact what we're able to do in the Verifiable Credential. There are
other protocols that don't have this limitation. The solution is
probably to NOT use that particular feature of OIDC because it will
inevitably lead to problems in browsers that don't support long URL
lengths. Feels like a non-starter for that particular flavor of OIDC
to me.

> - if a protocol has a flow with a size constraint in it, e.g. because it uses a redirect or a QR code, is it realistic to expect the user to know when to avoid this flow?

No, it's not reasonable to expect the user to know. The software they
are using needs to pick the appropriate mechanism, and ideally, that
mechanism doesn't have a tremendous amount of optionality (like OIDC
does). Much of the argument for OIDC has been "people have been
working on it for years and there's a ton of ways of solving problems
in the framework!" -- and the counter-argument to that is -- there are
many ways to get things wrong, and optionality works against
interoperability. Let's eliminate as much optionality as we can...
especially when we know a particular path will not lead to a solution
that works for many use cases.

> Or should every flow be built in such a way as to be unrestricted in the size of the data it can transfer e.g. by using a reference to an alternative endpoint that is not restricted in the size it can handle.

Remove the optionality. Remember, the user chooses the default browser
on their platform and the protocol has no choice over which browser is
invoked. If a protocol only works part of the time, and there is no
way to predict when it will/won't work; it's a bad protocol.

Hope that helps provide at least one opinion on the matter. :)

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Wednesday, 12 October 2022 14:40:55 UTC