Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/msporny/vc-http-api-spec
Verifiable Credential HTTP API Specification
https://github.com/msporny/vc-http-api-spec
Last synced: 2 days ago
JSON representation
Verifiable Credential HTTP API Specification
- Host: GitHub
- URL: https://github.com/msporny/vc-http-api-spec
- Owner: msporny
- License: other
- Created: 2021-07-18T18:56:51.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2021-07-18T20:49:43.000Z (over 3 years ago)
- Last Synced: 2024-11-09T05:39:15.257Z (about 2 months ago)
- Language: HTML
- Size: 286 KB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE.md
- Codeowners: CODEOWNERS
Awesome Lists containing this project
README
# [VC HTTP API](https://github.com/w3c-ccg/vc-http-api/) Goals
The W3C CCG VC HTTP APIs are a set of RESTful API definitions conforming with the [OpenAPI (formerly known as Swagger) 3.0 Specification](https://swagger.io/specification/) for the roles of Issuer, Verifier, and Holder as described in the [Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/) specification. These APIs provide a standard set of interfaces by which interoperability may be tested and verified by various parties who leverage Verifiable Credentials (VCs).
As some implementations may not support all endpoints defined by this specification, the APIs provide a clean measure by which to identify which methods are or are not implemented when comparing solutions that provide VC support across vendors.
Test procedures and specifications are provided as part of this API definition to allow for repeatable and automated interoperability testing between solutions that interact with VCs.
## Style, Versioning, and Contribution
This API is versioned in conformance with the [Semantic Versioning 2.0 specification](https://semver.org/) to prevent breaking changes between minor versions, and to allow for reliable testing and integration of implementations of this API within enterprise environments.API style, endpoint naming, and object definitions within the vc-http-api should be in compliance with the guidelines laid out in the [REST API Tutorial](https://restfulapi.net/). The VC HTTP API conforms primarily to the [controller](https://restfulapi.net/resource-naming/) model as detailed in the REST documentation.
The actual standard and specification defined by the vc-http-api is provided in [YAML format](./vc-http-api.yml) and should be referenced directly by developers should questions arise, as certain interfaces on top of OpenAPI specifications may differ in their presentation of certain scenarios commonly encountered in API definitions, especially when dealling with `nullable` parameters or properties.
Contributions to this repo should take place via a Pull Request, and should generally reference an issue and related discussion around the topic
## Best Practices
### Security
Implementations of this API SHOULD NOT be exposed directly over http(s) without authorization. Best Practices around OAuth and other widely accepted standards for authentication and/or authorization should be followed.
### Holder APIs
Holder APIs are optional as many implementations will not need them, however they are extremely useful for testing purposes as well as for cases where WebKMS is not present or not an option.
## Additional Documentation
- [Verifiable Credential Issuer HTTP API Architecture Model](architecture.md)
- [Verification, Validation, and Veracity](verification.md)