Holder: store <credential> #71
Comments
|
I guess the question is how does the Holder part of this API relate to the Universal Wallet interfaces? @OR13 |
|
The universal wallet has a set of abstract interfaces which can be mapped to the vc-http-api or vc-js, or other some custom process. They include:
There are a couple ways an issuer might push such a credential, but the universal wallet spec has no opinion on how that kind of thing would happen. In the past, we have used CHAPI to store credentials in a wallet. Another option would be to give the issuer a write capability to the holder's edv. both I think are slightly out of scope for this work item, which is focused on getting http api's to cover the core operations of the vc data model. |
|
This was discussed on the 2021-11-16 call, this came up in some of the data flows that @jandrieu is working on. There is an EDV, there is the ability to access that by people other than the holder, that's fair ground for having this conversation. What is the scope of the VC Issuer API? This falls in the category of what is the scope of VC API for an issuer. If we start with this being in scope, then it's clear that the request can indicate whatever. But I'm not clear how we are scoping the Issuer part of the API. I think of Issuer to be separate from Holder and Verifier. We have envisioned these endpoints as call and your'e done. We don't have async/interative flows -- initiate a flow, callback through different channel, that API for callback is fair game for scope. When you're "done" send it to my storage, async flow, we haven't teased out how to do it yet. If there is an issuer of a background check, background check could take up to 24 hours to happen... there is a 24 hour period where credential isn't available, but after background check is complete, you want to push to their wallet. This could be solved in other ways outside of this API, willing to let this issue sit until someone comes up with a concrete use case they want to see implemented. There may be other ways to solve this use case that don't impact this API. The group would like to see a concrete use case for this issue in order to have a more detailed discussion around this. Assigned to @agropper. |
|
Should a holder be able to store credentials and presentations using an http api? |
|
@OR13 - Do you have reasons why {an issuer, a holder, a verifier} should not be able to store {credentials, presentations} using an http api? I'm not sure that any of these need a devoted API (that is, I think one API signature could be used by all three for all two), but I might be missing something, in which case it seems that a 3x2 matrix should be set up and filled in... |
|
@TallTed its a question regarding the scope of the API... This api could define If adding and removing is out of scope for the VC API, it will likely be solved for elsewhere, and developers will gravitate to the apis that define all the functionality they need. its not clear to me that the w3c ccg wants to solve the problem of:
|
|
To the extent the VC-API begins with a Request to the Issuer and concludes
in Push or Pull access to a VC this as an authorization issue. Whether the
transport of the VC uses CHAPI, DIDComm, or etc... seems secondary to
consideration of how the Push or Pull is specified in the Request and how
the destination interacts with the Issuer. Support for asynchronous
fulfillment of the request is also a primary consideration.
For example, an EDV would be an authorized client to the Issuer.
…On Tue, Nov 16, 2021 at 5:34 PM Orie Steele ***@***.***> wrote:
@TallTed <https://github.com/TallTed> its a question regarding the scope
of the API... This api could define add and remove interfaces for
credentials and presentations... to date, it seems like folks are relying
on CHAPI / DIDComm for that kind of interoperability.
If adding and removing is out of scope for the VC API, it will likely be
solved for elsewhere, and developers will gravitate to the apis that define
all the functionality they need.
its not clear to me that the w3c ccg wants to solve the problem of:
- As a holder I can use the vci-api to store a credential I obtained
from "CHAPI/DIDComm/etc".
- As an issuer I can use the vci-api to store a credential I obtained
from "CHAPI/DIDComm/etc".
- As an verifier I can use the vci-api to store a credential I
obtained from "CHAPI/DIDComm/etc".
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#71 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YOXXUMTGS6IHVMGSBDUMLL6BANCNFSM4TX2XN3Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Note that at least one of us are using EDVs to do that... which is what @mavarley might have also been alluding to. We have delegation-aware storage/retrieval systems today (EDVs). That said, perhaps people want it to be more decoupled? |
|
This is not the edv working group or work item... its the vc-api, I don't think we should assume anyone is using EDVs here. If this vc api defines a store, retrieve and remove operation for credentials, I would be fine saying that it can be powered internally by EDVs, MongoDB, IPFS, or Identity Hubs... but I am very strongly opposed to mandating their use for |
|
PR add section in privacy considerations about issuer #830 is also directly relevant to this issue. |
|
This issue seems to have stalled. What is the next action item here? |
|
There are no "storage" endpoints defined for wallets / holders... that means no "add", "get", "remove", or "list" endpoints for holders. It seems that folks would prefer cloud wallets define such APIs elsewhere, reopen if you disagree. |
Preface: I'm new here. I'm opening this issue at @troyronda 's suggestion.
I was wondering if it makes sense in the context of this API to have a Holder operation to support an issuer pushing a Verifiable Credential into a "credential repository" of a Holder. This operation would require the Issuer to have the authorization of the Holder to store a VC in a repository.
The text was updated successfully, but these errors were encountered: