Re: Issuing a credential to a subject that doesn't exist

Hi Liam, here's one approach using DIDs:

1. Generate a new random DID using a method that supports rotatable private key control of DID Document.
2. Issue referral credential with that DID as the subject.
3. Send the referral credential to friend along with private key, even before they install the app.
4. After they install the app and ready to claim the referral credential, they must rotate the DID Document access keys so the original private key is no longer valid to control, but their new key is, which issuer does not know.
5. Friend issues new credential from their existing DID to claim the referral DID as one of theirs.

A few caveats:
- Step 4 could cost a pretty penny depending on what DID method you use
- There's an attack vector where issuer does all sorts of nasty things with referral DID before issuing the credential, and then "friend" claims the new DID as one of theirs.

On Thu, Aug 20, 2020, at 7:01 PM, Liam McCarty wrote:
> Here’s a puzzle:
> 
>> Suppose you want to issue a credential, but the subject doesn’t exist yet. You don’t have a subject DID to include in the credential, and you don’t have a place to send the credential anyway! Is there a way to still issue a credential?
>> 
>> As a concrete example, let’s imagine you’ve installed an app and you want to refer a friend to install it, too. And when they install the app, they should get a “friend of you” credential, issued by you. 
>> 
>> Now, it’s natural to imagine your app instance as the issuer and their app instance as the subject/holder. But your app doesn’t know what to put for the subject DID or where to send a credential because, well, they haven’t installed the app.
>> 
>> One approach to resolve this is what I’ll call “delayed issuance”: when your friend installs the app, their app says to your app, “hey I’m ready for that credential, send it over!” This would work pretty well if your app were a server, always listening for their app. But your app isn’t a server and can’t be relied upon to be available.
>> 
>> So perhaps this "request for credential issuance” could be stored temporarily somewhere, and then your app could check for it when it’s next opened. That would usually work, but it would break badly if you delete your app, never open it again, don’t open it for a long time…
>> 
>> The only resolution seems to be for your app to authorize a server to act as an issuer on its behalf — which maybe means the server is the only real issuer at all. Then their app can asynchronously request a credential to be issued whenever it exists. 
>> 
>> Does anyone have any thoughts on this?
>> 
> I think the better approach that remains compliant with the W3C specs is something more like the following:
>  1. There’s a server that does the job of checking whether one app install was the result of a referral from another app instance. That server is the issuer.
>  2. When you send your friend the referral link, that link amounts to a way for the server to check whether your friend actually installs the app as a result of your referral. It can then issue a credential based on that.
> In this approach, your app is not an issuer in any sense. This doesn’t seem to be meaningfully different than any other existing referral program — it’s certainly not peer-to-peer. I suppose each app could authorize its *own *server to be the referral referee. But that just seems extremely inefficient.
> 
> Does anyone see a way to do something like this in a peer-to-peer decentralized way (that’s not extremely inefficient)?
> 
> *Liam McCarty*
> Co-Founder of Unum ID <http://www.unumid.org/>