search

w3c-ccg / vc-api

A specification for an HTTP API used to issue and verify Verifiable Credentials.
https://w3c-ccg.github.io/vc-api
Other
123 stars 46 forks source link

Should this API define how to host revocation lists? #232

Open OR13 opened 2 years ago

OR13 commented 2 years ago

Previously discussed in: https://github.com/w3c-ccg/vc-http-api/issues/204

Currently, RevocationList2020 assumes a revocation list is hosted somewhere resolve-able.

And https://github.com/w3c-ccg/vc-http-api/blob/main/issuer.yml#L37

implies that this API changes that credential wherever it is hosted, yet this API provides no way of obtaining that credential.

peacekeeper commented 2 years ago

In my mind, this is out of scope.. We define a standard way of updating the status of a credential, but how that is achieved (e.g. how the revocation list is constructed and where it is hosted) should be up to the individual implementation.

At least that's how I would see it, but I don't feel strongly about it, so I'm not really opposed to adding more detailed definitions related to this.

OR13 commented 2 years ago

@peacekeeper thanks for commenting!

If the API enables you update certain kind of credentials (CCG Work Item Revocation List Credentials), the API should let you get them, since getting them is required to verify them, and verifying them is already under test.

https://github.com/w3c-ccg/vc-http-api-test-suite/blob/main/packages/vc-http-api-test-server/__fixtures__/verifiableCredentials/case-15.json#L21

mkhraisha commented 2 years ago

I think it makes a ton of sense for you to be able to resolve a list. I don't think this should be an explicit route though, I believe it should be included as part of the verification route.

OR13 commented 2 years ago

@mkhraisha @peacekeeper I am not sure I agree... How can we rely on hosted revocation lists if we don't have any tests that implementations support hosting them... right now the only reason tests are passing is that we are all using github pages...

https://github.com/w3c-ccg/vc-http-api-test-suite/blob/61d498cd04c45a22b9578774e6a066b59a8f4e94/packages/vc-http-api-test-server/__fixtures__/verifiableCredentials/case-14.json#L21

An API that defines operations related to revocation should define them completely or not at all...

jandrieu commented 2 years ago

I'm with @OR13 on this one. Both the storage systems and the revocation/status mechanisms currently lack interoperability precisely because we keep excluding them from the overall architecture. However, where you store your VCs and how you check revocation status is fundamental to the system.

For example, we could provide a way for verifiers to directly retrieve the VC from the holder's storage. That would require some form of additional authorization and an additional communication channel. Current flows assume the VC goes from the issuer to a holder-controlled wallet to a verifier. This existing flow does not ensure an authorization mechanism for the holder storage to allow remote access, which reduces the attack surfaces, at some cost in flexibility. In short, where we put the storage matters to the VC API.

Similarly, we could say that the verifier app is responsible for performing revocation/status checks, but I expect that would be a bad design choice. IMO, the apps contain the business logic of their controlling party (issuer app instantiates the issuers business rules), while services provide the generalizable functionality particular to VCs precisely so the controlling party doesn't have to implement all the intricacies of the underlying tech. In my opinion, different revocation/status check mechanisms are best aligned with a service that is dedicated to maintaining that functionality, rather than a burden of the party maintaining business rules. In addition, they should be completely substitutable. If I'm using a verifier service that doesn't support the revocation means for a credential, the verifier should be able to substitute with a service that can. Even better if my existing verifier had a configurable architecture so I could just substitute the revocation check while still using the same verifier service.

Unless we identify these roles formally we will not have an API for them and, as a direct result, will not have a standards-based mechanism for substitutability. People will be stuck with however their wallet manages storage and revocation APIs will remain non-interoperable as each is going to get developed independently without support for a common API. In particular, I believe it is vital for us to establish a revocation status check API that explicitly avoids identifying the VC and/or subject directly. A standard API for revocation checks can make it clear that to be compatible with the VC architecture, your revocation service must expose an API that is not a simple phone home check against a correllatable identifier.

At a minimum, IMO, we need to identify all the components that come together to realize the entire flow of Verifiable Credentials, and the APIs used for each of those. This includes storage and revocation checks.

msporny commented 2 years ago

The group discussed this on the 2022-05-24 telecon. @peacekeeper noted that a revocation list is specific to a specific revocation status mechanism, so we might not want to apply it to a single mechanism, not universally applicable. @dlongley noted that we might want to reduce verifier contact issuer to increase privacy -- one thing in revocation design is to express credentials, verifier could request credential and revocation credential at same time, so holder could deliver both. Presumably VC would have to be fresh enough for what verifier requries, could respond to verifier and include in request -- could handle privacy preserving aspect like thiat. @jandrieu noted that for both revocaiton and refresh, there was a sense that these are points of extensibility, but we should probably have one example so that people can see how whole stack works together. There was some agreement for one example of both of those mechanisms in scope for us to figure out. Eric mention that it would be good to have a use case, use cases don't call out revocation explicitly, someone might need to write a good example of revocation use case to figure out if it's in scope or out of scope. Manu noted that there were three options -- put it in VC spec, put it in VC API spec, keep it separate from VC API and point to status list 2021. @jandrieu noted that refresh and revocation are a part of the VC API, I'd question why isn't that endpoint is part of the spec? @peacekeeper noted that there is a question around test suites -- issuer, ed25519, refresh test suites... is that an argument for making it more modular? Manu argued that his preference would be to make this modular. @dlongley noted that people have been arguing for ONE normative example of extension points. @msporny noted that we can point to modular specs normatively. @dlongley noted that we can provide a hook in the VC API for sending a revocation list to the verifier. @dlongley noted that we might put the details of how credential status mechanisms work wrt. holder->verifier delivery of credential status information into the credential status specification. @kezike noted that we need to think about how often status list credentials are retrieved and cached. @dlongley noted that it's going to be a business rule, mostly, but we should talk about it in the spec.

The proposal is to talk about status/revocation in the VC API and point to a normative status/revocation mechanism from the spec as a concrete example of how to implement the feature. The spec that is pointed to should contain all the data models and protocols required to implement the revocation mechanism as well as guidance to maximize privacy when possible -- ideally, the verifier SHOULD NOT contact the issuer to check status information and SHOULD get that status information from the holder. A PR to implement this is in the VC API and a status list mechanism is welcome.