VC-API JFF PlugFest 2 Questions

Hi there,

Calling on issuers in the JFF PlugFest 2 cohort and practitioners generally
that implement the VC-API spec as a means of delivering credentials with
the following questions:

   - If you support the */exchanges* endpoints, how do you communicate this
   endpoint to wallets? QR code containing just the exchanges endpoint? QR
   code containing a native deep link or a web app with the exchanges endpoint
   as a query parameter? If the former, wouldn’t the issuer need to choose a
   wallet on behalf of the holder (which defeats the purpose of this
   plugfest)? If the latter, would the issuer send a link (via email, text,
   etc.) to a webpage that leverages CHAPI to enable wallet selection? Would
   the information delivered to the selected wallet then be used to initiate a
   VC-API exchange (e.g., exchange ID)?
   - If you support the */exchanges* endpoints, since the exchange ID is
   generated by the issuer and is intended to be opaque to wallets (per the
   spec), does this mean that issuers should randomly generate a new exchange
   ID for each instance of a given workflow (e.g., foo123 and bar456 may be
   two separate exchange IDs that each map internally to a credential request)
   and deliver it to holders offline? Or would the issuer publicly define all
   exchange IDs (e.g., request-credential, refresh-degree) that they support
   including request and response schemas? If the latter, why is it necessary
   for these IDs to be opaque, when they capture the intent of the holder?
   - Which actors are authorized to access which endpoints? For example, I
   understand why endpoints like *POST /credentials/issue* should require
   OAuth to prevent an unauthorized caller from issuing credentials. Is it
   also necessary for the exchanges endpoints to use OAuth in order to limit
   interactions to holders that the issuer recognizes? In this case, it feels
   as though it is the responsibility of the issuer to define appropriate
   scopes for different users, but the definition of such scopes is currently
   left to the discretion of the issuer, correct?
   - Is *GET /credentials/{id}* considered an issuer-invoked endpoint or a
   holder-invoked endpoint? This endpoint can be interpreted either as a means
   for an issuer to retrieve all credentials that they have issued or for a
   holder to retrieve all credentials that the issuer has still made available
   for them. If both interpretations are correct, this is another place where
   scope definition is critical.
   - If OAuth is required for holder-invoked endpoints, where in a VC-API
   workflow should they request access tokens?


I would be glad to create GitHub issues for these questions in the VC-API
spec if it would help, but for the sake of time, I figured this forum would
be a good place to start the conversation.

Cheers,

Kayode