Re: credential "recovery" or "reissuance" terminology

> 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
>>
>>