The interaction between an identity wallet and a website has several potential use-cases, which can be broadly classified into two categories - Mobile wallets and Browser extension wallets. While both these categories have their respective utilities, browser extension wallets offer a unique advantage. Unlike mobile wallets, they enable smoother interactions as there is no need to switch contexts or devices. The wallet can pop up right where it's needed on the screen, offering a more streamlined user experience.

There are several specific use-cases for the interaction between an identity wallet and a website:

1. Registration and Sign-In: Often referred to as "Sign in with DID" or "Log in with DID", this use-case involves using the private key pairs to sign something, proving control over a specific DID. This action is akin to demonstrating one's unique identity, allowing the user to log in or register on a particular website or service.
2. Exchange of Credentials: In this scenario, the user provides verifiable credentials to prove a certain fact or authorization to a website. Examples could include demonstrating the right to perform a particular action, proving qualifications, or validating one's human identity. This set of credentials can also be used to authorize someone else. Conversely, the website might request the user to sign a credential, which it then stores or holds.
3. Message Exchange: A website might send messages to the user's wallet. These could range from notifications to requests, which can be responded to at a later time. For instance, the website might be processing some data and wants to notify the user 24 hours later that the process has completed.Often referred to as "Sign in with DID" or "Log in with DID", this use-case involves using the private key pairs to sign something, proving control over a specific DID. This action is akin to demonstrating one's unique identity, allowing the user to log in or register on a particular website or service.

The communication between the website or service and the wallet is facilitated through various channels. These channels can be used exclusively or in combination for a richer user experience:

1. Out-of-Band (OOB) Messages: These structured message formats are frequently used in the SSI space, such as when scanning a QR code. Often, this channel is used to initiate an interaction and handshake, typically through scanning a QR code on a website.
2. HTTP: OOB messages often define an endpoint or page to visit, like for onboarding (registering). This channel facilitates one-way communication from the wallet to the website, allowing a response to come back.
3. Script Injection and Background-script/Service-worker: This method, popular with crypto-wallets, involves injecting code into the website that can be executed by the user, like clicking a button. A message is then sent through this channel to the wallet and, if necessary, a response is sent back. While this could technically be two-way, in practice, it's primarily one-way since the wallet needs to know which tab and website to address.
4. DIDComm This channel supports full two-way interaction, but it has to be first established by any of the previously defined methods.

The interaction between the wallet and website is further defined by specific protocols:

1. PRISM Onboard & Authenticate: Developed by the PRISM team, this protocol is integrated into the PRISM enterprise agent offering. It comprises two sub-protocols:
1. Onboard: This defines the method to register a DID for a website or service.
2. Authenticate: This defines the method to register a DID for a website or service.
2. blocktrust legacy sign in(depreciated) The initial sign in protocol used by the blocktrust identity wallet, introduced as a proof-of-concept July 2022. This protocol is still be compatible to the latest build of the identity wallet.
3. blocktrust legacy authorize (depreciated) The initial credential-sharing protocol, also introduced as a proof of concept in July 2022. This protocol is obsolet, since the credential sharing for the purpose of authorization can better be accomodated by using DIDComm.
4. blocktrust legacy signing (depreciated) This protocol was initial also demoed as a proof of concept in July 2022 with the focus of signing already prepared Credential-Issuing operations. This is currently not supported anymore.