nebolsin Thanks so much for the thorough response and clear reasoning. Those are all legitimate reasons to keep a transaction off-chain, especially for the genericity and speed. I don’t think privacy is really an issue considering what is stored on the network and I personally disagree that refunding is not a scaleable model. It’s actually quite common for services to refund or comp network fees.
nebolsin In SEP-10 challenge transaction includes cryptographically strong random nonce, and the issued JWT is linked to the challenge transaction through jti claim. So when it's necessary the implementation can keep track of the nonces and provide strong replay guarantee, but in simpler cases you can keep auth service stateless which is a lot easier.
Great point. This is something I actually do in StellarAuth now via the memo and a double hashed SHA token.
nebolsin SEP-10 is intentionally minimalistic and only focused on the authentication (not authorization, which can be defined by higher-level SEPs or by the particular service like StellarAuth). It defines a simple challenge-response flow which allows a client, identified by Ed25519 public key, to prove the possession of the corresponding secret key to an external service and exchange it for service-specific auth token. It's designed to be implemented by wallets, and it puts minimal required restrictions on the service side of the process to support as many use cases as possible.
Also fair enough. I think fundamentally SEP-10 is a really good starting point for building on top of with slightly higher level services like StellarAuth. Gives some good guidelines for best practices and how you would create a baseline for authentication. What it really needs is some strong implementation use cases you could point to so folks could get how it’s meant to be used.
nebolsin And before diving into SEP-10/StellarAuth compatibility discussion, I would love to better understand the use case StellarAuth is targeting. Can you please share some specific examples of how projects would integrate and use StellarAuth?
For sure, and I’ll have to tip my hand a little here, StellarAuth is the beginning of something much larger for me. I’m not ultimately targeting existing Stellar users or just login. The next iteration of StellarAuth will actually be a signing wallet which can be managed directly by applications. In my mind Stellar is a low level library not a high level service. For Stellar to succeed it will need to be adopted as a transparent service where users have little to no idea of secret keys or copying and pasting xdrs or remembering bip32 phrases. It will need to be much much simpler than it usually is.
This has become incredibly clear to me as I’ve worked on Colorglyph 2.0. Most of my work since launching that app has been around how do I build modern usable applications utilizing everything Stellar has to offer while not limiting my audience to an existing and limited user base of crypto savvy nerds? I want to build for usage not users. I want Colorglyph to be appealing to anyone, not just those with existing Stellar accounts or those who have the knowhow or courage to dive into it. I want my mom and brothers, my sisters and cousins, my neighbors and friends, very few of which do or will ever care about Stellar as a company, to be able to jump right in and play with minimal technical friction. This will require a massive shift from our current thinking when it comes to how we build Stellar apps and who we build them for.
For me that boils down to abstracting Stellar away into services other applications like Colorglyph can implement to gain all the benefits of Stellar without having to surface any technical friction directly to their users. StellarAuth is the linchpin for this initiative. An onramp into the network which is managed by applications but controlled transparently or familiarly by users. The goal would be for StellarAuth to have a client facing web, mobile, browser extension app which serves as a sort of Authy or Google Authenticator for Stellar. The permissions gateway for applications to perform actions on a users account. Much like StellarGuard or Lobstr Vault do today. The big difference is that StellarAuth will be both a signing app and a wallet. New accounts can be created transparently from the application side much like you would add 2FA to an account today. From there future transactions submitted to the network would pass through this client app for the final yes/no.
This is obviously far from what StellarAuth is today, though not as far as it may seem. It is clear then that for my use case funded accounts and actual transaction submission to the ledger would be baked into what StellarAuth would be doing. If StellarAuth was just authenticated web sessions than SEP-10 would likely be sufficient, but as you can see I have bigger goals than just login.
All that to say there probably isn’t much or anything that needs to change with SEP-10, it’s been an incredibly helpful SEP along with SEP-7 for guiding the future of StellarAuth and ensuring I’m building a compliant, secure and usable service.
