Skip to content

Should Credential Schema be Stored on the Ledger ? #418

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Vishwas1 opened this issue Feb 16, 2022 · 4 comments
Closed

Should Credential Schema be Stored on the Ledger ? #418

Vishwas1 opened this issue Feb 16, 2022 · 4 comments

Comments

@Vishwas1
Copy link

Not-An-Issue

I have been going through w3c did implementation guide and found this line here.

Avoid storing credential schemas on ledgers.

Previously, what I had understood was, didDoc and schema both need to be present in the public ledger. The verifier of verifiable presentation can fetch this schema from the ledger and check is this credential follows a particular format or not. For example, Directorate General Of Civil Aviation (DGCA), India can publish a schema for airTicketCredential - what format all airlines ticket should be. Now every airline company can use this schema to issue airline tickets to passengers. The passenger can present the airTicketCredential to the security guard (notice security guard is not part of any specific airline company), who can then verify this credential by connecting to publicly (or privately) accessible ledger.

But after reading the above line in the document, I am totally confused. Could some please explain the concept here? Have I totally misunderstood the concept?

@kdenhartog
Copy link
Member

This comes down to a difference of opinion. Some people, such as the Indy community, saw it as beneficial to store these on the ledger in order to create common shared semantics. Others found it useful to rely on things like JSON-LD and schema.org in order to achieve shared semantics. Ultimately, the concern here is that since this is an architectural pattern that's not shared throughout every did method it was recommended to not do this since it may hurt interoperability because other methods will have chosen a different architectural pattern and make it more difficult to have cross interoperable did methods.

@Vishwas1
Copy link
Author

Vishwas1 commented Feb 16, 2022

@kdenhartog thanks again for reply.

But in case where schema is not registered on the ledger, then how custom formats are checked (which may not be defined in schema.org)? Like for example, if a VC is of type UniversityDegreeCredential or airTicketCredential, how does verifier know what all fields credentialSubject should contain? Am I a missing something here?

For example,

In this example, the type UniversityDegreeCredential in the VC must be coming from the context https://www.w3.org/2018/credentials/examples/v1 but who gets to define that context ?
image

Sorry if these question are too naive.

Thanks

@peacekeeper
Copy link
Contributor

@Vishwas1 I think you may also find an ongoing PR in the vc-data-model specification helpful, which discusses the use of contexts and schemas: w3c/vc-data-model#847

In any case, this is probably the wrong place for this topic. This here is about the registry for DID Core extensions. Your question may better fit into one of these repositories, and you may get additional answers there:

@Vishwas1
Copy link
Author

Vishwas1 commented Feb 17, 2022

@peacekeeper thank you for your reply and apology for posting wrong question here. I will ask my questions in those forums.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants