Wallet requests DIDComm channel but issuer did not demand / offer it

[ArPhil]

Consider the following scenario:

The issuer does not offer an optional DIDComm channel, nor does it require a DIDComm channel in its metadata, which is fetched by the wallet before starting the openID4VCI flow.

How should the issuer behave in this case?

• Should it ignore any incoming DIDComm channel requests?
• Should it accept incomming DIDComm channel requests?
• Do we have to initate another (not yet defined) DIDComm protocol in order to handle this?
• Should we abort the whole issuance flow?
• Is this use case specific?

We need to figure out, how to handle this.

[janawueTUB]

My thoughts: As long as the issuer does not offer nor require a DIDComm channel, we should ignore incoming requests. I can't imagine a use case where a DIDComm channel is needed but there's no evidence for this in the metadata. If this is the case, the issuer's metadata must be adjusted. Accepting any incoming DIDComm request feels a bit shady to me and I see no reason for this behaviour - if a DIDComm channel is necessary it should be stated in the issuer's metadata.

[janawueTUB]

After our biweekly call on Monday we came to the conclusion that we only build a DIDComm channel if the scope parameter is present because otherwise it is not relevant. If there is no scope parameter in the Token Request any try to build up a DIDComm channel won't be a success.

[ArPhil]

Closed.