-
Notifications
You must be signed in to change notification settings - Fork 47
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
Elaborate on service configuration #443
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. I'd been wondering how to proceed on #419 and maybe this PR helps move that issue forward as well.
Instance configuration can include, but is not limited to, credential format, key options, credential status mechanisms, and/or credential templates. | ||
Administrators are expected to configure service instances such that `options` included in client requests cannot result in incorrect action or problematic responses by the service. | ||
The APIs defined in this specification presume that they are attached to a | ||
specific instance of some kind with an associated configuration that has been |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, the "of some kind" text is superfluous
specific instance of some kind with an associated configuration that has been | |
specific instance with an associated configuration that has been |
For example, the `/credentials/issue` endpoint is expected to be at the end of a | ||
longer URL such as `/instances/12345/credentials/issue`. In this case, it is the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need to be at the end of longer URL? It seems reasonable to me that one could direct to specific instances in other ways. For example, one could use subdomains to address an instance or an internal service discovery mechanism.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, I made a suggestion in my review.
<p class="note" | ||
title="Use cases can use multiple instances for complex flows"> | ||
A coordinator instance can have access to multiple service instances in order to | ||
support different use cases. Runtime discovery of service instance configuration | ||
is not supported by the VC API as services are expected to be known by the | ||
coordinator at the time of coordinator deployment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, the current title is too narrow. In my mind, a single coordinator could support multiple use cases and so might need multiple service instances, even the each use case flow is "simple". So having the title suggest that the main use for multiple instances is "complex" flows is too narrow.
<p class="note" | |
title="Use cases can use multiple instances for complex flows"> | |
A coordinator instance can have access to multiple service instances in order to | |
support different use cases. Runtime discovery of service instance configuration | |
is not supported by the VC API as services are expected to be known by the | |
coordinator at the time of coordinator deployment. | |
<p class="note" | |
title="A coordinator can use multiple service instances"> | |
A coordinator instance can have access to multiple service instances in order to | |
support different use cases or a use case with complex flows. Runtime discovery of service instance configuration | |
is not supported by the VC API as services are expected to be known by the | |
coordinator at the time of coordinator deployment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might also want to say that "Using multiple service instances, such as different workflows, can also be used to improve a deployment's security profile by limiting the privileges that a coordinator needs to operate. One way this can be done is by restricting the inputs a coordinator can provide when creating an exchange to just a few variables in a workflow-specific template." Or something along these lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving with some suggestions.
</p> | ||
<p> | ||
A coordinator instance can have access to multiple service instances in order to support different use cases. | ||
Runtime discovery of service instance configuration is not supported by the VC API as services are expected to be known by the coordinator at the time of coordinator deployment. | ||
For example, the `/credentials/issue` endpoint is expected to be at the end of a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For example, the `/credentials/issue` endpoint is expected to be at the end of a | |
For example, the `/credentials/issue` endpoint can be provided at the end of a |
to configure an instance, or be aware of the setup that the administrator did on | ||
the instance. Administration endpoints for configuring instances could be | ||
provided by implementations but are not necessary to expose as HTTP APIs; | ||
configuration can also be done through configuration files or graphical | ||
interfaces. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clients do need to know what is expected to happen when the admin hands them the URL, but otherwise, yes:
to configure an instance, or be aware of the setup that the administrator did on | |
the instance. Administration endpoints for configuring instances could be | |
provided by implementations but are not necessary to expose as HTTP APIs; | |
configuration can also be done through configuration files or graphical | |
interfaces. | |
to configure an instance, or be aware of the setup that the administrator did on | |
the instance other than the requisite details to make appropriate use of it. | |
Administration endpoints for configuring instances could be | |
provided by implementations but are not necessary to expose as HTTP APIs; | |
configuration can also be done through configuration files or graphical | |
interfaces. |
<p class="note" | ||
title="Use cases can use multiple instances for complex flows"> | ||
A coordinator instance can have access to multiple service instances in order to | ||
support different use cases. Runtime discovery of service instance configuration | ||
is not supported by the VC API as services are expected to be known by the | ||
coordinator at the time of coordinator deployment. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might also want to say that "Using multiple service instances, such as different workflows, can also be used to improve a deployment's security profile by limiting the privileges that a coordinator needs to operate. One way this can be done is by restricting the inputs a coordinator can provide when creating an exchange to just a few variables in a workflow-specific template." Or something along these lines.
Administrators are expected to configure service instances such that `options` included in client requests cannot result in incorrect action or problematic responses by the service. | ||
The APIs defined in this specification presume that they are attached to a | ||
specific instance of some kind with an associated configuration that has been | ||
put in place by a systems administrator. When a client calls an endpoint on a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
put in place by a systems administrator. When a client calls an endpoint on a | |
put in place by a system administrator. When a client calls an endpoint on a |
Software clients that call a particular instance might not have the capability | ||
to configure an instance, or be aware of the setup that the administrator did on | ||
the instance. Administration endpoints for configuring instances could be | ||
provided by implementations but are not necessary to expose as HTTP APIs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
provided by implementations but are not necessary to expose as HTTP APIs; | |
provided by implementations but are not necessarily exposed as HTTP APIs; |
This PR attempts to address issue #267 by documenting how service instance configuration works.
Fixes #267.
Preview | Diff