- From: Stephen Curran <swcurran@cloudcompass.ca>
- Date: Tue, 2 Jul 2019 18:04:10 -0700
- To: Kim Hamilton <kimdhamilton@gmail.com>
- Cc: Daniel Hardman <daniel.hardman@evernym.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAFLTOV6i4JMoVq8dDMyv1Pbm1dz+=OGiyn+MkEUb7K06pjC_QQ@mail.gmail.com>
We think that "reissuance" is the most common case for revocation. Something changes (not necessarily a bad thing as implied by the term "revoked") and because the credential is digital, it's easy to revoke and issue new. Example - drivers licence change because of a new address. That will be WAY more common than revocation because the licence represented by the credential is no longer valid. At BC Registries, where we are issuing credentials for all Registered Organizations in BC, even a dissolution of a company results in a revocation and a reissuance with a status of "Dissolved". On Tue, Jul 2, 2019 at 5:05 PM Kim Hamilton <kimdhamilton@gmail.com> wrote: > > I think the terminology for such flows should be identical to that of > original issuance *except* that it has a new step early in the process-- > "revocation" of the old credential. So "reissuance" = "revoke old" + "issue > new", whereas ordinary issuance = "issue new". > > good point, and I'll use "reissuance" for now > > On Tue, Jul 2, 2019 at 4:36 PM Daniel Hardman <daniel.hardman@evernym.com> > wrote: > >> My 0.02: >> >> Reissuance can happen for many reasons, not all of which are recovery >> scenarios. For example, reissuance might be needed due to a a name change >> associated with a life event, because of a typo in the original credential, >> or because the issuer needs to replace a compromised issuance key. >> >> I think the terminology for such flows should be identical to that of >> original issuance *except* that it has a new step early in the process-- >> "revocation" of the old credential. So "reissuance" = "revoke old" + "issue >> new", whereas ordinary issuance = "issue new". >> >> >> On Tue, Jul 2, 2019 at 5:16 PM Kim Hamilton <kimdhamilton@gmail.com> >> wrote: >> >>> This should be straightforward, but I couldn't self-help from the VC >>> data model. >>> >>> Assume subject == holder for now (just in case being different would >>> complicate things) >>> >>> In my scenario, Alice issues a Verifiable Credential to Bob, the subject >>> of which is did_b (controlled by Bob). Then suppose for whatever reason, >>> Bob loses ability to lose control of did_b*. >>> >>> In this state, the credential is still valid (hasn't been revoked, >>> hasn't expired), but Bob can't prove control of did_b. Do we have special >>> terminology for this state and/or verbs involved? E.g. Bob will need to >>> "recover" or "request a re-issuance" of a credential from the issuer. >>> >>> The VC lifecycle doesn't seem to call out separate states/verbs for >>> this, which I can understand. Ultimately the flow is the same, and it >>> results in an "issuance". But when describing user stories around systems >>> using VCs, it's often necessary to call this out, and it would be helpful >>> to use standard terminology if available. >>> >>> * i.e. suppose he's using BTCR, failed to backup the info he needs to >>> update did_b, and for simplicity, loses his phone, never made a backup of >>> his mnemonic seed. Bad Bob. >>> >>> p.s. I'm sure I made the question more complicated more than it needed >>> to be >>> >>> -- Stephen Curran Principal, Cloud Compass Computing, Inc. (C3I) Technical Governance Board Member - Sovrin Foundation (sovrin.org) *Schedule a Meeting: **https://calendly.com/swcurran <https://calendly.com/swcurran>*
Received on Wednesday, 3 July 2019 01:04:46 UTC