From 07faf3d9f8130f83c1d4ff64eee88c7d0f0bda63 Mon Sep 17 00:00:00 2001 From: wes-smith Date: Tue, 13 Feb 2024 12:33:07 -0500 Subject: [PATCH] Apply editorial suggestions to added text. Co-authored-by: Ted Thibodeau Jr --- index.html | 64 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 33 insertions(+), 31 deletions(-) diff --git a/index.html b/index.html index b29ed42..ee98008 100644 --- a/index.html +++ b/index.html @@ -570,38 +570,40 @@

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