Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

msporny
Copy link
Contributor

@msporny msporny commented Jan 29, 2025

This PR attempts to address issue #267 by documenting how service instance configuration works.

Fixes #267.


Preview | Diff

Copy link
Contributor

@jrhender jrhender left a 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
Copy link
Contributor

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

Suggested change
specific instance of some kind with an associated configuration that has been
specific instance with an associated configuration that has been

Comment on lines +681 to +682
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
Copy link
Contributor

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.

Copy link
Contributor

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.

Comment on lines +695 to +700
<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.
Copy link
Contributor

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.

Suggested change
<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.

Copy link
Contributor

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.

Copy link
Contributor

@dlongley dlongley left a 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Comment on lines +689 to +693
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.
Copy link
Contributor

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:

Suggested change
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.

Comment on lines +695 to +700
<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.
Copy link
Contributor

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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
provided by implementations but are not necessary to expose as HTTP APIs;
provided by implementations but are not necessarily exposed as HTTP APIs;

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

Successfully merging this pull request may close these issues.

Document Instance Configuration in the VC API
4 participants