As it stands right now, although we aim to be chain agnostic, our tools are mostly built with Ethereum in mind.
We are actively working on multiple specs to “Sign-on With X” using a multitude of providers. The
did-session package will ultimately help us achieve the ability to allow developers to plug in whatever blockchain provider they want to as long as there is a standard in place. For example, Sign In With Ethereum (SIWE) is much more mature than Sign In With Solana (SIWS). The spec for SIWS is still actively being written.
I am unfamiliar with Fireblocks, but after taking a quick look at their site it does seems as though they will allow an integration with Ethereum. Although you may be making a design decision to not build on Ethereum, which is okay too.
I also don’t fully understand Fireblocks’ place in the tech stack, so it’s hard to say if there would ever need to be support for Fireblocks. I think what makes more sense is support for the chains that Fireblocks integrates with.
did-session is really built with browsers in mind, it’s main purpose to allow delegation from the user to the application through the use of browser sessions. So with that in mind, it probably doesn’t make much sense for Fireblocks to be an integration with
did-session if they don’t use browser based authentication.
I don’t think any of this get’s you closer to resolving whatever blocker you are coming up against. It may be easier to help if we know what your authentication flow looks like and how you are trying to use
did-session in your application.
What I can point you to is the section on authentication in our docs. This covers authenticating with Ceramic without using 3ID, and you can do this outside of the browser if needed.
You could use 3ID DID as you mentioned above for outside of the browser things, but I would be cautious to start a new project using 3ID Connect as we are moving to
did-sessions for better session and capability management throughout the application.
As far as “recommended” way, I can’t answer that without knowing more about the process/workflow you are trying to build.
Hopefully that helps some, I’ll tag @zfer who works much closer with our authentication packages than I do. If I missed anything critical he would be the person that could fill in the blanks for us