w3c-ccg
Issuer API does not expose issuer identifiers and supported crypto suites
We address with in trace interop with https://github.com/w3c-ccg/traceability-interop/blob/main/docs/discovery.md
However, previously we have addressed this with well known did configuration.
And originally this was all hard coded into a "service provider JSON" which was used by the original test suite.
Can you explain this a bit more? Is the idea to introduce an API endpoint or other mechanism that allows the client to "discover" the list of available issuers and other configuration metadata?
yes, per the comments @dlongley made regarding configuration here: https://github.com/w3c-ccg/vc-api/pull/263#issuecomment-1048187195
Currently the client needs to know some information about the server in order to craft a valid credential issuance request... or the client needs to accept that the server will apply whatever defaults it has.
The defaults case does not support the feature validation use case, and currently we rely on external configuration to set that stuff... (json files that test suites consume).
I suppose that @dlongley original comment could be interpreted as suggesting that such configuration (either in client side json files or on a service side discovery endpoint) is a bad idea, as it leads to potential complexity...
I opened this issue to gather feedback on "should the VC API Issuer endpoints support multiple issuers and multiple suites, and if so, how..."... They do today... either by client side json configuration or server side discovery.
If we remove the ability to choose issuer or verification method or suite, the API becomes a lot simpler... but also a lot less useful for testing feature based interop.
If we remove the ability to choose issuer or verification method or suite, the API becomes a lot simpler... but also a lot less useful for testing feature based interop.
Where actual real world use comes into conflict with ease of implementation of testing feature-based interop, we should prioritize the former. But this may not be such a hard thing to resolve for the latter anyway. We may be able to just have people list multiple issuer URLs (that match specific feature configuration sets) to do feature-based interop testing.
@dlongley can you comment on https://github.com/w3c-ccg/vc-api/issues/267
Its hard to understand what you are advocating for without a complete picture of your vision.
This issue is blocked by the lack of defined GET endpoints...
I think most users would expect:
GET /issuers
=>
{
items: [ { id: 'foo-bar', type: 'JsonWebKey2020', verificationMethod: 'did:example:123#key-0', ... },... ]
}
Then they could implement support for adding new issuers with:
POST /issuers
Update a specific issuer with:
PUT /issuers/{id}
Delete a specific issuer with:
DELETE /issuers/{id}
Until there is consensus on such basics, I don't see how this issue can be resolved.
We discussed this on the 2022-05-24 call. @dlongley noted that he's a big fan of issuer URL endpoints that are configured with concrete settings for cryptosuites, issuers, credential types, credential status mechanism, zcaps, oauth credentials, etc... a static configuration for a particular issuer endpoint. Using that endpoint should not require sending any sort of options, so you post the credential you want issued, if you send a valid credential, you get an issued credential. With respect to discoverability, @dlongley does not think it makes sense to have configurability at endpoints -- process to issue credentials is to create issuing configuration and add it to your software. @jandrieu agreed with @dlongley -- it's the issuer app that's talking to issuer service, and issuer app drives service endpoint, it knows what that service is doing on behalf of the app. Not understanding use case where issuer app needs to do some sort of discovery because app was configured to use service. @msporny noted that we need feedback from @OR13 and @mavarley. @dlongley noted that that came out of a world where we were designing for a test suite -- a demo -- we quickly bootstrapped showing features of API, but when you get to real world use cases, it doesn't function that way. We need to modify how we do test suits where we provide specific configurations for specific tests you run. That models how you set up applications in real world. Andy Miller noted that IMS Global has two specification that support dynamic client registration -- LTI and OpenBadges, the use case there is that in the case of Open Badges, badges are hosted somewhere, collected on a host/wallet but you want to move them to another service -- with dynamic client registration, if both sides support it, application that's being used can reach out and discover endpoint that other host that want to move to, what it supports, and can facilitate registration that's needed and then start process of moving badges. The use case in both cases is when an individual wants to do something w/ their data, use/move to different app that the current platform is not aware of yet, and they can't go through whole process in an easy way to get platforms to talk to each other. This facilitates all of that -- dynamic registration uses service discovery. @dlongley noted that Andy's use case is an important one, but does not fall under issuer API -- that API doesn't mean badges would be re-issued, have to contact each individual issuer, so what is being talked about is concept of a host and move existing badges to a different place. Not related to what issuer API is going to do. @dlongley noted -- not that we're going to say "we don't need to express configuration information", it's fine to GET configurations (load and see what config is), but we don't need to do that in support of a discovery API -- not endpoints are highly optional -- you should be able to fetch configuration (but use case isn't to browser endpoint and hope you can issue something). @jricher noted that we might be punting registration/discovery -- there are arguments for static registration, but there are also arguments for having machine-readable parameters -- there will be a handful of things you can do with static configs, and there are uses for dynamic configs -- not in conflict for having instance. @dlongley noted we can use static configs to support dynamic registration. The difference is discovery of all possible features and choose/send to an endpoint, because that doesn't work w/ the specific stateful endpoints that we have. Important that we have step where config is stateful and breaking these things apart -- what are we discovering -- features available instead of existing options that could be used.
The current proposal is to expose a configuration for an issuer endpoint and note the issuer id, cryptosuite, allowable credentials, revocation mechanism, and other relevant details to provide the basis for discovery for that endpoint. It is unknown currently how that particular configuration endpoint is discovered, that is for another issue.
It was suggested that a PR describing the issuer endpoint configuration is welcome, which may or may not overlap with the discovery endpoint that Avast provided.... but there were concerns. Looking to @dlongley @mavarley @jricher and others to continue the discussion here.
expose a configuration for an issuer endpoint and note the issuer id
My confusion on this language is in part because I understood @dlongley's suggestion that the discovery endpoint is to discover features of the issuer service.
When you say we expose a configuration for an issuer endpoint this feels to be far more specific. That for a given endpoint, a route on a server, the configuration will be discoverable.
So, my questions are
- What is being discovered?
- Who is doing the discovery?
Regarding #2, it seems that if the Issuer App is making these calls to the Issuer Service, it is significantly different than if these calls are being made by Holder Apps or Verifier Apps (or something else).
In order to support "discovery" we need to say what is being discovered. On the call it became clear that what it may make sense to discover are the set of features a particular issuer may provide -- which is different from discovering a particular configuration (aka "issuer instance").
So the flow for dynamic configuration would be:
- Get the list of features from the issuer.
- Create a valid configuration (aka "issuer instance") from a selection of features.
- Use that issuer instance (via its endpoint) to issue VCs.
What does not seem to make sense is having a client dynamically "discover an existing configuration and then use it".
Additionally, none of this is directly related to the separate issue of getting the configuration information from an already created issuer instance. This should also be possible by sending an authorized GET request to the issuer instance endpoint. I would expect the main use case for this endpoint would not be "discovery of a configuration to use", but rather be to make changes to an existing configuration:
- Get the existing configuration from a known issuer instance (via its endpoint).
- Apply a change to that configuration.
- Send the updated configuration in a POST to the issuer instance.
This approach also enables conflict resolution if the configuration includes a sequence number that must match an expected value.
@dlongley I believe that it's more semantically appropriate for a discovery step against a single, configured endpoint to be an OPTIONS request and not a GET request.
I think having instances and configs (and the endpoints for getting instance configs, etc.) defined in the spec should cover this issue. To that end, I recommend we close this by saying that this will be covered by what we said we need to do in a PR here:
https://github.com/w3c-ccg/vc-api/issues/267#issuecomment-1478494037
If we find that that PR (when it happens) is insufficient in any way, then at that point we can add to it or open a new issue for further discussion on what's needed.
The group discussed this on the 2023-06-06 telecon. @dlongley noted his comment above (this is a duplicate of #267 and PRs raised to address that issue will address this issue). @dmitrizagidulin noted that this is not needed. The issue API is one of the backend APIs in the spec and it could be argued that when you set up the backend, you know which DIDs it supports because you enabled them in the config. Discovery is needed when unfamiliar clients are using your service, and the issuer API is definitely not one that is used by unfamiliar clients.