Samuel Smith 

Kent Bull  

Phil Feairheller 

Henk van Cann

Neil Thomson

Rodolfo Miranda

Randy Warshaw

Shawn Butterfield

Daniel Hardman

Michal Pietrus 

Ruth Choueka

Kevin Griffin 

Joseph Lee Hunsaker 

Mark Scott 

Click here for → Zoom meeting Oct 25 2022


Agenda

  • Announcements 
    • Daniel - Interesting debate in W3C, Let JSON be JSON.  Debate over being forced to use JSON-LD and @context 
      • https://github.com/w3c/vc-data-model/issues/947#issuecomment-1290600092
      • Almost identical to the same discussion about requiring JSON-LD in DIDDocs.
      • Proposal in the thread to evaluate alternatives on their technical merits...  an opportunity to put forth ACDCs as an alternative
        • Term compatibility.  Solution in DIDDoc spec was a registry for specification on how to convert between syntaxes.
        • DID Doc Spec solution is a registry of interoperable round trippable conversions between syntaxes (serialization)
      • Extensibility is Overrated.
        • Extensibility is the ability to ignore fields you don't care about.
        • Credential is evidence of entitlement.  Driver license example...  the license itself can just be the entitlement and the additional forensic information can be chained with ACDC as a follow on credential.
        • Developers are highly comfortable with that way of developing their features (looking at docs, inspecting return values and referencing the fields they need)… JSON-LD would instead require that developer to implement a data expansion library that takes an extra 2sec at runtime just to reason about the format/type/meaning of a property
        • JSON-LD is a dynamic look-up of a URL resource for VC schema. This is unstable as the URL resource may change without notice. A more stable model is schemas available for retrieval via a SAID for version specific and a Persistent Identifier for a version collection. This points to JSON-Schema to provide references to data schemas (via SAIDs and/or Persistent Identifiers) vs. JSON-LD
      • Layer semantic transformation on top of secure ACDCs with immutable, authentic schema.  
      • When thinking about protocol design it is important to remember that the stack goes in reverse between presenter and verifier.  And the verifier gets the data coming off the wire and needs to trust the data and the source of the data before you start processing the application layer aka, semantics.
        • As you work your way up the stack, the envelopes from the previous layers can be preserved and referenced in subsequent layers.  
        • You need to keep the authentic envelopes to prove provenance of the data, this feature brought to you be end-verifiability
      • 2 Ways ACDC can help W3C
        • ACDC provides a model - Immutable schema, append to extend, property graphs through chaining
        • ACDCs can be used as a layer below the WC3 data model.  Use ACDCs as the authentic envelope around W3C verifiable credential.
      • Meeting on November 1st to discuss the Let JSON be JSON issue and come to a resolution
      • As a community, we should all comment on the GitHub issue in W3C, (https://github.com/w3c/vc-data-model/issues/947)
      • KERI and ACDC are IETF and if W3C is a big tent then great
        • We should make our arguments clear about WHY we favor this approach, not argue to force the W3C to change
        • Should be about adoption
  • IPEX   DEP  
  • No labels