A workflow for issuer-initiated Credential Offer should be an option

[ottonomy]

Credential flows sometimes start from a holder contacting an issuer to request a credential. Perhaps much more frequently, an issuer initiates the process of generating a credential that is offered to a subject/holder to accept. It seems important to outline how the issuer-initiated flow can occur, perhaps prior to the issuer and recipient negotiating on a specific DID that would be used as the subject identifier. Ideally both of these options are covered:

Offer a Credential to a Recipient who is signed into your website

• An authenticated user has a session in their browser with Issuer Service
• The user does something amazing that qualifies them for a credential
• The Issuer Service offers the recipient a credential
• The recipient presents and proves control of a specific identifier and confirms that they can support a specific wallet interaction protocol.
• The credential is signed and presented to the subject/holder's wallet

Offer a credential to a Recipient who has already earned some credentials issued to a specific DID

• The user is back!
• The user does something else worthy of a credential.
• The issuer service issues another credential, which is signed and presented to the subject/holder's wallet

[OR13]

This would seem to be a request for an interface between an issuer website and a holder wallet (mobile app, web app, or web service).

We have this section of the spec for linking to such solutions: https://w3c-ccg.github.io/universal-wallet-interop-spec/#protocol

The problem is that none of them really work today (except for CHAPI, which has its own set of challenges).

[OR13]

It would be good for us to define these flows and then comment on which concrete solutions solve for them today, and their drawbacks.