From 07faf3d9f8130f83c1d4ff64eee88c7d0f0bda63 Mon Sep 17 00:00:00 2001
From: wes-smith Authorization
mechanism agnostic.
-The VC API is meant to be a generic API that can be useful in many -scenarios that require the issuance, possession, presentation, and/or -verification of Verifiable Credentials. As such there are the following -classifications of use cases that the implementer should consider. -
--Public. A Public API is one that can be called with no authorization. -Examples include an open witness or timestamp service (a trusted service that -can digitally sign a message with a timestamp for an audit trail purpose), or -an open retail coupon endpoint ("15% off cheeseburgers"). Public verifiers -may exist as well, acting as a agnostic third party to a trust scenario. -
--Permissioned. Permissionsed authorization requires the entity making -the API call to have an access control token issued from a mutually trusted -source. These permissions grant access to the API but make no assumptions -about credential subjects, previous interactions, or the like. Permissioned -access is particularly useful in service-to-service based workflows, where -credential subjects are not directly involved. -
--Bound. Bound authorization involves scenarios where the API calls are -tightly coupled, linked, or bound to another out-of-band process that has -authenticated the holder/subject to the API interaction. These use cases include -but are not limited to, for example, issuance of subject specific identity claims -directly to the subject in question, or verification of credentials to qualify the -holder for service at the verifier. Examples of methods to bind activity on one -channel to a VC API call include CHAPI, OpenID Connect, and Grant Negotiation -Authorization protocol. Developers implementing bound authorization will need to take -steps to ensure the appropriate level of assurance is achieved in the flow to properly -protect the binding. +The VC API is meant to be generic and useful in many scenarios that require +the issuance, possession, presentation, and/or verification of Verifiable +Credentials. To this end, implementers should consider the following +classifications of use cases:
+The rest of this section gives examples of the authorization technologies that have been contemplated for use by conforming implementations. Other equivalent authorization