Holder service endpoint discoverability

[brianorwhatever]

How can an Issuer issue a credential to a holder that is using a DID method that doesn't contain a service property (ie. did:key)?

[brianorwhatever]

Options I've considered:

1. holder uses a did:peer
2. holder responds with a request-connection from either DID-Exchange (RFC 0023) or Connections (RFC 0160) protocols to the service-endpoint in the OOB message
3. use a did method that uses a ledger (ie. did:ion, did:cheqd)
4. add another attachment into the propose message
5. holder uses did:web

reasons I don't like these methods:

1. did:peer appears to be no longer maintained
2. adding more didcomm protocols into the flow adds complexity. this could ideally be done in a connectionless manner
3. I am hoping to avoid writing endpoints to a ledger
4. this isn't really being done atm so how would others know to look there?
5. having a holder host a webserver doesn't seem ideal. I wonder if there is something we can do with the message routing and have the message come from a mediator?

[rodolfomiranda]

We are using did:peer since as in did:key we can relay only in internal libraries. It's critical to be able to create DIDs per connection with rotation to new one easily and cheap. That's why 3, 4 and 5 are not suitable. That's the first time I hear of did:peer not being maintained. I'd ask Daniel Hardman opinion on Discord.

[vongohren]

I will share what we are trying. Just linking some context of conversations. JFF Concern sheet: https://docs.google.com/spreadsheets/d/1ntGKxERXOAlazV8QcwcqShUG_5g0IN9jtVYPw5GTR-Y/edit#gid=853131589 A conversation in DIDComg user group: https://discord.com/channels/900385725462229022/1029863865191764008/1029868708576890880

What we are doing now: We are embedding the service endpoint in invitations, inspo from: https://github.com/hyperledger/aries-rfcs/blob/main/features/0023-did-exchange/README.md. Which Brian puts as option 2.

We dont have any issues to try out 1. did:peer and see how that is done, but have the same concern as Brian, as did:key and other things are being more properly adapted.

But would love to also see if 2. would be an option. But yes, you might have to do a OOB initiation protocol. Unless issuance-request message could also contain a service endpoint. Is this possible? Then it is possible to directly jump to issuance request with a "discoverable" service endpoint

[brianorwhatever]

So looking further into did:peer it is essentially the same as option 2 as it requires the did exchange protocol. https://identity.foundation/peer-did-method-spec/index.html#create-register

[brianorwhatever]

I'm still not clear on if the did:peer spec requires a protocol to resolve a did. do you know @rodolfomiranda?

I have also created a strawman did method which just base64 encodes a doc.. could be another option

edit: link to did:based

[rodolfomiranda]

With did:peer is straightforward, you don't need a protocol. You start from an OOB invitation where you get the did:peer of the other party. Resolve it internally and get the endpoint. Then submit the reply to that endpoint. There are examples in code in the didcomm guidebook: https://didcomm.org/book/v2/startConnection

[rodolfomiranda]

We have a wallet and a mediator fully implemented with DIDComm v2 and did:peer (using SICPA libraries, JVM and Python)

[brianorwhatever]

ok yeah that is what I had thought originally. The wording here is strange in that I thought you needed to communicate the document that the did is associated with. as long as it can be resolved offline with just the identifier its an option for this use case imo

[rodolfomiranda]

Honestly, I just used the libraries without getting into the details.

[brianorwhatever]

On call - Discussed how this comes down to:

1. use did method with service endpoint
2. use did exchange
3. another attachment path

We decided on using option 1 as did resolution shouldn't be difficult for some of the methods and can always use universal resolver