- From: Liam McCarty <liam@unumid.org>
- Date: Thu, 20 Aug 2020 18:01:39 -0500
- To: Credentials Community Group <public-credentials@w3.org>
- Message-Id: <9FFDE6AD-36AD-4BF9-A796-6F54D8E3E26F@unumid.org>
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: 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. 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/>
Received on Thursday, 20 August 2020 23:02:23 UTC