Way to embed an endpoint for .well-known discovery in an OOBI

[iFergal]

Feature request description/rationale

In controlled deployments of KERI for particular use cases, it can be easier to bootstrap agents with schemas. (e.g. all the signify tests use the vLEI test server for vLEI related schemas)

I would like a generic way for a mobile wallet (in my case) to discover schemas from new contacts. Since schemas are cryptographically bound to their SAID, OOBIs work well and don't have the overhead of signing etc. @pfeairheller has suggested using .well-known at an endpoint.

From this point, I still need to discover the endpoint hosting these schemas for a particular issuer, which may be different to the controller/agent URL, especially if this is KERIA and not a web service built on top of keripy.

Discovery of this service endpoint via the OOBI makes sense to me, but then this service endpoint wouldn't really have a KERI role since there isn't a KERI agent behind that URL. It's just for discovery. Not sure if I'm going down the wrong path here. It feels like an anti pattern for a "service endpoint" to not have a KERI identifier at the domain.

Alternatively (just thought of this now), KERIA could automatically serve these so the domain would be the same. Would need to be controlled more tightly, but that's a general problem for KERIA to figure out.

[pfeairheller]

As long as the service endpoint is attested to in a signed rpy message using BADA-RUN, I don't believe there is a requirement that they endpoint itself only contain information directly related to the AID. Exposing a "schema" endpoint is a perfectly valid use case.

From the KERI spec:

An important use case for BADA-RUN is to process OOBIs that provide service endpoint discovery of the AIDS of KERI components. These components include but are not limited to, Controllers, Agents, Backers (Witness or Registrar), Watchers, Jurors, Judges, and Forwarders.

Even though KERIpy uses an enumeration (sort of) for role names, the spec is very clear that we are not limited to those roles. To me, this falls under the KAPI (KERI API) domain and should be a simple API defined to start with a service endpoint with a given role (I really like registrar but that is overloaded in the spec already) and a defined set of routes off of that service endpoint for discovering schema. It could be off of .well-known, but I don't think it has to be (and I'm not sure it makes sense when it would be just as easy to define a few routes for schema discovery).

That would define the rules for schema discovery. Have any issuer expose a service endpoint with a role of schema-discovery-thingie then any verifier knows what API to hit against the URL of that service endpoint to get a list of exposed schema and how to resolve each schema exposed.

[pfeairheller]

In terms of how the API is defined, I see two choices with may or may not be mutually exclusive.

We could define a simple HTTP REST API with proper verbs and paths for schema discovery, or a KERI event message API with proper message types and routes (the r field) for discovery. To see what they might look like side by side, consider an API for getting a list of available schema at an endpoint...

HTTP REST: Method: GET, path: /schema
KERI Events: Event Type: qry, resource: /schema

In both cases, the return would be the schema JSON streamed back. If you tightly define which roles are required to provide this API, it seems evident that the most straight forward role would be issuer.

[pfeairheller]

With the REST API, you wouldn't need anything more than a web server, propery formatted index file and a new role
And with either API, the API should allow you to create the URL for a schema with the combination of the Issuer's service endpoint and the schema SAID. And this is secure because of the binding between the SAID and the SAD of the schema and the cryptographic commitment to the schema in the issued credential.

[iFergal]

Thanks Phil, as further discussed on Discord makes complete sense!

In the coming weeks I'll give a go at the new role and a way to add it (most of the work might be at the KERIA level then), at first starting with the REST route for simplicity. Will report back!