Re: Decoupling AnonCreds from Hyperledger Indy

Hey Orie,

Thanks for the pointers on the next steps regarding the vocab. Something
which could be cool to explore as another side note could be defining vocab
terms in a Collection of on-ledger resources and identifying them with a
DID URL - although not quite as user friendly yet 😄

In terms of how resolvers handle the custom path component, each unique
resource version has its own UUID, so a path like the example in my
previous email will always return the resource itself. This section of our
DID Resolver ADR
<https://docs.cheqd.io/identity/architecture/adr-list/adr-001-did-resolver#resolve-representation-function>
shows
how "linkedResourceMetadata" is included and structured within the resolved
representation of DID Document Metadata.

This metadata itself may also be able to be queried by resolvers to return
specific metadata about the resource (such as a resource version at a
specific time). We've now compiled a draft set of query-based parameters
within a ToIP draft specification (see the section "Query Syntax for
Resource DID URLs" here:
https://wiki.trustoverip.org/display/HOME/DID+URLs+for+Digital+Resources+Specification
".

Hope this helps answer your question.

Alex

On Tue, 4 Oct 2022 at 23:51, Orie Steele <orie@transmute.industries> wrote:

> Great work!
>
> Regarding:
>
> > Next stop - AnonCreds in a W3C conformant JSON-LD wrapper!
>
> I suggest you start with this:
>
> "@context": [
>     "https://www.w3.org/2018/credentials/v1",
>     { "@vocab": "https://vocabulary.example#" }
>   ],
>
> This will automatically provide term IRIs for your terms, and then you can
> just define them in markdown or whatever.
>
> Here is an example website on github that can manager terms:
>
> https://vocabulary.transmute.industries/ns/attestation
>
> Example of what I mean.
> <https://v.jsld.org/3NqVbvW2sdJ6vjM8F1qu8fd3LGzzV7MuMCwSZRd2sYeEKvqgkQSbxfX1BEhVUpWK3abnrnqsd3idxJJkedHUKVXgnn3S5PKF12gqedbS75RA1m91EmAVSEn5dn9Yx3ANNux3S3r6B8sWj3ZaSAvv7py8tmrbB36xZravcBhjptqbFgREzM45XpcsGxKJnJc1idXvM2rWuEiacknempgYs3aZDxHRnwBwUhRbUZYXKPXuNQyc9F9R1eBWB86uQHUrxKheriKWbgjLaNBF5Y5Q4tEZMkNPrcKP4X733pSmXPPonRfWdx4HwpgzNUSKmcSeSRwqRXVfiRcjK93MkGUoxmwkJ739k2gpRkBoTwtV6kXGz4XkSEddSLepSnoXZ64fzP91LkKrSnUdChCBeESEAYU8eE1j6szEpAVV2bH3DS7TBV88zEAmuqPK6c9XqubsAGeB7Q>
>
> As an aside note, it's nice to see a DID URL with a PATH component:
>
> did:example:123/resources/4e2ba734-ae3d-4ca3-9657-c717c3dd6184
>
> How do resolvers handle this?
>
> Regards,
>
> OS
>
>
> On Mon, Oct 3, 2022 at 8:27 PM Alex Tweeddale <alex@cheqd.io> wrote:
>
>> Hey CCG community 👋
>>
>> I thought I'd write a message to share some contributions we've been
>> making at cheqd to broader community interop, since I feel like many of you
>> may be interested and have valuable feedback/contributions.
>>
>> *1. Decoupling AnonCreds from Hyperledger Indy*
>>
>> Last week, we were able to demonstrate our approach to decouple AnonCreds
>> from Indy by reworking all the custom Indy-transactions (CL-Schemas,
>> CredDefs, RevRegDefs/Entries) into DID Core conformant transactions.
>>
>> Using cheqd's new resource module
>> <https://docs.cheqd.io/identity/ledger-resources/resources>, we were
>> able to replicate each AnonCreds-specific object in a DID URL syntax, which
>> can be supported by any other Layer 1 chain. You can dig further in our blog
>> here <https://blog.cheqd.io/anoncreds-indy-pendence-4946367469d4>, and
>> our detailed docs on how this actually works here
>> <https://docs.cheqd.io/identity/ledger-resources/using-on-ledger-resources-to-support-anoncreds>
>> .
>>
>> As an example of what an AnonCreds Object is represented, here's an
>> example of a RWoT AnonCreds schema that works!
>>
>>
>> did:cheqd:testnet:zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZ/resources/4e2ba734-ae3d-4ca3-9657-c717c3dd6184
>>
>> Which you can resolve using a DID resolver to fetch the actual resource
>> from the cheqd ledger:
>>
>>
>> https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZ/resources/4e2ba734-ae3d-4ca3-9657-c717c3dd6184
>> <https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:z:zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZ/resources/ea5168a0-1253-4819-abf5-f937fa8cac16>
>>
>> This removes a degree of vendor lock-in from the Indy / AnonCreds tech
>> stack, and begins to move things in the right direction there. Next stop -
>> AnonCreds in a W3C conformant JSON-LD wrapper!
>>
>> We demo'd this work alongside Animo Solutions, building cheqd AnonCreds
>> into Aries Framework JavaScript and you can watch the demo here
>> <https://www.youtube.com/watch?v=QILE98VMwZw>.
>>
>> We will also be presenting this at DIF Interop on 5th Oct B Call (11am
>> ET).
>>
>> *2. Support for JSON, JSON-LD and AnonCreds on-ledger AND in SDKs*
>>
>> I *believe *we have achieved a bit of an interop milestone by providing
>> both on-ledger support and SDK support for both sides of the SSI community
>> divide - JSON based VCs as well as AnonCreds.
>>
>> On the JSON front we have built our own cheqd SDK
>> <https://github.com/cheqd/sdk> which we have incorporated into Veramo
>> SDK as a module, forming the Veramo SDK for cheqd
>> <https://cheqd.io/blog/building-decentralised-identity-applications-on-cheqd-with-veramo>
>> .
>>
>> You can use this now to create/manage cheqd DIDs
>> <https://docs.cheqd.io/identity/building-decentralized-identity-apps/veramo-sdk-for-cheqd/did-operations>,
>> create/manage on-ledger resources
>> <https://docs.cheqd.io/identity/building-decentralized-identity-apps/veramo-sdk-for-cheqd/create-a-resource>,
>> issue/verify JSON based VCs
>> <https://docs.cheqd.io/identity/building-decentralized-identity-apps/veramo-sdk-for-cheqd/verifiable-credentials>
>> and VPs
>> <https://docs.cheqd.io/identity/building-decentralized-identity-apps/veramo-sdk-for-cheqd/verifiable-presentations>
>> anchored on cheqd.
>>
>> We'd LOVE to explore integrating into other JS based SDKs, so if you're
>> building one please reach out.
>>
>> *3. Status Lists, Trust Registries, on-ledger Governance and more*
>>
>> We've noticed a LOT of community discussion around Governance, Trust
>> Registries and Status Lists recently. I think there is a real opportunity
>> for community collaboration about how we can use the resource syntax to
>> expand to all of the above.
>>
>> Since every resource is associated with a DID and DID Document,
>> verification relationships and keys used to manage DID Documents can be
>> extended to managing resources.
>>
>> This presents an opportunity to create Trust Registries, where authorised
>> parties may have associated keys to manage a DID, which then extend to
>> update/manage the entries of the Trust Registry on-ledger.
>>
>> We're currently looking at standardising the approach to resources here
>> <https://wiki.trustoverip.org/display/HOME/DID+URLs+for+Digital+Resources+Specification>,
>> but we would love to collaborate on work that utilises this for Trust
>> Registries or extends this to other SSI infrastructure.
>>
>> ~~
>>
>> Very keen to hear the community's thoughts on our latest contributions,
>> and whether you agree with our design choices - you can take a look at all
>> our other Open Source work on our GitHub here <https://github.com/cheqd>.
>> Feel free to get in contact with myself if you are interested in
>> collaborating on any of the above.
>>
>> Alex Tweeddale
>>
>> Governance & Compliance Lead
>>
>> Schedule a meeting
>> <https://calendly.com/alex-tweeddale/introductory-call>
>>
>> cheqd.io <https://www.cheqd.io/> | Twitter <https://twitter.com/cheqd_io>
>> | LinkedIn <https://linkedin.com/company/cheqd-identity> | Telegram
>> <https://t.me/cheqd>
>>
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>