1F/ Making Digital Creds That Last for Decades / Ankur Banerjee

From IIW

Session 1F

Making digital creds that last for decades: Using DID URLs as permanent pointers to Schemas, Visual Design, Trusted Issuer Lists, Revocation Etc.


Session Convener: Ankur Banerjee (cheqd) Notes-taker(s): Scott Phillips (Trinsic), Ajay Jadhav (AyanWorks)


Tags / links to resources / technology discussed, related to this session:


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


  • What happens when the issuer no longer exists?
    • E.g., if there were KYC credentials issued by the FTX exchange?
    • Computer History Museum (IIW venue) is literally an archive of old technology - how hard is it to play 90s flash games, nintendo cartridges, etc?
  • How do we make a statement about identity?
  • Schemas are naturally used in traditional documents (lots of US drivers licenses have shared content)
    • They change visual format, but sometimes content/attributes are added
    • Systems need to understand and check associated schema from the time the credential was issued
    • We need to have version managed schema archives, so that we can find the old version of the schema
  • We still have a single point of failure when storing schemas at a web URL - think about the Facebook outage of 2021-10-04
  • The major cloud infrastructures are centralized and concentrated, 66% of the world's cloud infrastructure is AWS/GCP/Azure
  • "Linkrot" breaks links on the web, all the time - columbia school of business - close to 60% of links from 1998 are dead, 40% from 2008 are dead
  • We still have the question of visual representation of credentials
    • Allow the issuer to create a visual guidelines so that the owner can pick it out
    • Sometimes you get into different queues are the airport based upon the color of the loyalty card
  • Canada has internationalization requirements about issuing every credential in French and english
  • Keybase.io (owned by zoom) - allows people to show logos and favicons for claimed social media profiles


Crypto public/private key storage (and rotation) over the course of 10 years

IETF Yang is a schema modeling language to define how schema can evolve over time RFC 6020

Fundamental assertion that credentials can be extremely long-lived. We should practice credential hygiene

We should have human readable and machine readable schema and governance files


  • Think about liability in business, discovery as part of litigation
  • Sometimes old credentials are valid for only certain activities (eg prove age with an old driver's license, but cannot drive)
  • Create DIDDoc for Resource collection (eg for a schema)
    • Create a resource (and uid) tied to a resource collection (and uid)
    • Need diddoc controllers to update the credential as it evolves
    • Specify unique link to the resource (eg on cheqd mainnet)
    • You can have previousVersionId and nextVersionId that allows you to link to new or old versions of the did
    • This is the checksum of the did, different media types
  • Discoverable resources: did method prefix, Resource Collection ID, module path, Specific Resource ID
  • Took inspiration from from IPFS
  • Query based syntax for a given resource collection id
  • DID Core needs to have a standardized way to support resources
    • GIS did similar thing: They started with the basics, all the providers did similar things, then GIS standard adopted those things into the standard
  • Max block size is 200KB, you can't put a video on the blockchain
    • There is nothing preventing resourceUri from have IPFS url or an https url
    • Multiple places availability for redundancy
  • If you want to stop reusing schemas, maybe have copies in different locations
  • DID Core is finalized, but DID Resolver is still open to modifications
  • Maybe there is a schema that is published on did:ion or did:polygon you want to use - no problem. Everyone is doing did resolution already
  • trustoverip confluence page: suggested optional vs required resource parameters
  • Just because something might be a bad choice, doesn't mean we are going to prevent you from making that choice.
  • Checksum should be a required, IPFS has it as hash-link/content ID of the file
  • The whole point of did resolvers and did urls specs mean that you don't need to natively support every ledger/blockchain
  • Goal is: W3C and DIF adoption for the did resolution spec that Cheqd wants to extend


What about blast pattern and DIDDoc overloading?

  • Was it deactivated because it was compromised, or because it was outdated
  • Have 1 or more did docs or did keys to publish schemas, another doc to publish resources, etc.
    • This helps reduce the blast pattern
  • You can traverse using DID URLs


Action items / next steps:


Contribute or comment/feedback on TOIP Wiki for DID-Linked Resources: Working copy/draft of this spec is currently on TOIP Wiki but the objective is to turn this into a specification either as an extension of W3C DID Resolution specification or its own specification at W3C.

Retrieved from "https://iiw.idcommons.net/index.php?title=1F/_Making_Digital_Creds_That_Last_for_Decades_/_Ankur_Banerjee&oldid=24541"