Add directory of schema in schemas.json file

[SmithSamuelM]

@dhh1128 @m00sey Because each schema has a universally unique SAID maybe for the sake of automated discovery we should have a schemas.json file with an object that maps each schema's said to the URL of the associated schmea file within each schema folder on this site . This way, someone could crawl the schemas.json file to discover any schema given a SAID of a schema. Essentially schemas.json is a table of schema OOBIs. The pull request to add a schema should also include updating the schemas.json file. This way we have a content addressable directory of schemas.

contents of schemas.json

{
"EFablekdnflkdne": "urlofschemafile",
"Ebceiopst8ele9s": "urlofschmeafile"
}

[SmithSamuelM]

@dhh1128 Adding discussion from pull request

PR #12 somehow got polluted with an extra branch of commits. This has exactly the same intent as that PR, but keeps the commit history clean.

Create a mechanism for trivial discoverability, as suggested by @SmithSamuelM in #7 (comment).

I had to fix some minor incompleteness in the bindkey folder to include it in the registry.

A few questions to reviewers:

I decided to use the filename registry.json rather than schemas.json because the file doesn't contain schemas; rather, it is the embodiment of the registry concept that maps schemas to URLs. I updated the README to say that the repo "has" a registry instead of "is" a registry. Hopefully this clarity seems good to you -- but I don't feel that strongly. If you prefer schemas.json you can talk me into it. Another rational name might be index.json...

I used absolute rather than relative URLs. Do you agree with this? Part of my reasoning is that we could allow the discovery of schemas published elsewhere, by keeping this convention.

I made no attempt to use a URL that attempts to guarantee immutability (e.g., that contains a git commit hash). I figure the SAID of the schema provides this benefit so we can use more normal (and shorter) URLs. However, this has the possible drawback that the schema can get unregistered (even without the registry file being updated) if a commit renames the file. Does that concern you?

The names of the VLEI files seem unnecessarily long to me. They all contain the word "credential" even though that's obvious from context. They also all contain "vlei" even though that's the name of the folder. But more importantly, some use abbreviations and others probably should. "OOR" is an acronym in some file names and spelled out in others. I'm not sure we need "legal-entity" as a prefix on the ECR and OOR items. "Authorization" could be "authz". Etc. I made no attempt to tweak any of this, obviously, but fretted a little as I was copying the long filenames into the registry file. If you want a PR from me to regularize and shorten the names, let me know.

[SmithSamuelM]

@dhh1128 I agree registry.json is a better name than schemas I agree with not putting a hash in the URL since the SAID of the schema is a hash, a user can verify that the schema at the URL matches.

My only concern with external URLs is that the registry can have only one entry per schema. This might induce a URL squatting where a pull request puts a popular schema on someone’s web site in order to draw traffic and collect information about users of the schema. We would then as maintainers have to police pull requests for external URLs. So for this reason I have concerns about external URLs. If we changed the json from a simple mapping object (one said to one schema) to an array of schema URLs then we could support absolute URLs and let the consumer of the .json decide which URL to source the schema from. That way its easier to police since we just enforce that someone can’t delete an entry unless the entry is stale (i.e. does not have the schema). Control over the source can be verified because prior to the pull request whoever controls the source can delete the schema so that a lookup of the URL fails which means the entry in the registry is stale and can be deleted and an imposter who does not control the source can’t fake the URL breaking. This makes the discovery more robust (i.e. redundant sources are possible)

In contrast, using relative URLs so that schema can only be in the repo, removes that temptation and the burden. Since the SAID is universally unique, then as long as the schema validates against the said, it won’t matter who sourced the schema in the registry. So it becomes a “permissionless” registry. Any copy of a schema with the same SAID must be the same schema, so its doesn’t matter the source of the registry entry as long as the said verifies. So URLs with hashes just mean one more thing to verify without adding any additional robustness.

Since this is a “permissionless” registry, in that its up to each maintainer of a schema to ensure their registry URL entry that points to the schema subdirectory is valid.

The only thing what we would need to keep the repository clean is an automated test suite on pull requests that looked up each URL and verified that the schema at the URL verified against the said in the schema before adding to the registry. And that periodically checked all URLs (especially external ones) to see if the links were stale. Any stale links are removed from the registry.

As for the verbose vLEI names. That is a GLEIF thing. Lets talk about registry naming conventions at the KERI meeting this morning. I think this would be a good topic for the call.

Thanks for the pull request!

[SmithSamuelM]

I accepted the pull request since I don’t have strong objections and it works. But I think it would be good to discuss in the KERI meeting to see which way to go.

• only one entry per said with relative URL
• only one entry per said with absolute URL
• multiple entries per said with absolute URLs (or one relative and the rest absolute)

[SmithSamuelM]

Based on discussion in KERI mtg 2023/05/16

One entry with relative URL
relative URL is the github pages so that scraping the URL returns the schema not the github page

Add either test to verify entries in registry.json on changes or add code to autogenerate registry.json on pull request to any of the schema subdirectories.