Re: Performance question for JSON-LD with vc.js

On 03/04/2020 03:06, Leonard Rosenthol wrote:
> David - in that model, does that mean that you ignore all contexts that you don't have "pre-configured"?

We don't ignore them. Our verifier code rejects any VCs with @contexts 
it does not recognise. Our Holder wallet will however properly store and 
forward any VC with any @context from any known issuer.

Kind regards

David

>    Are they at least properly stored and forwarded, as required?
>
> Leonard
>
> On 4/2/20, 4:38 AM, "D.W.Chadwick" <info@verifiablecredentials.info> wrote:
>
>      Hi Anil
>      
>      I can assure you that JSON-LD processing is not needed in order to
>      implement a VC eco-system. JSON processing is all that is needed, along
>      with pre-configured @context definitions
>      
>      Kind regards
>      
>      David
>      
>      On 01/04/2020 07:51, Anil Lewis wrote:
>      > Team,
>      > Verifiable credentials are based on JSON-LD and after reading
>      > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmanu.sporny.org%2Fcategory%2Fjson-ld%2F&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cdc259566d2b14a5c14aa08d7d6e131ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214135021849674&amp;sdata=e22S%2FryitHj7LLeyBtJvCYhaZKwYWLGOgwmM0wH95fo%3D&amp;reserved=0  , I am a bit concerned about
>      > performance. Has anyone used vc.js and associated libraries in scale
>      > in some pilots? I understand the recommendation from the article is to
>      > cache the contexts but have pilots that have used this strategy with
>      > substantial number of learners see any issues with json-ld processing?
>      > Note that I am referring to the examples provided in
>      > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c-ccg%2Fvc-examples&amp;data=02%7C01%7Clrosenth%40adobe.com%7Cdc259566d2b14a5c14aa08d7d6e131ec%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637214135021849674&amp;sdata=kiUDtI6U9XsBBmAPlNAtMf1kNB79Ax8fG18iGZT41ts%3D&amp;reserved=0
>      >
>      > .
>      
>      
>      
>

Received on Thursday, 2 April 2020 18:52:43 UTC