Forgive me, I'm typing this one with my thumbs.
Consent-Based Authorization (CBA) is a means of requiring consent in order to access a resource. This differs from other schemes which require separate authentication and authorization steps in a number of important ways. It provides a number of advantages over existing schemes which will become more apparent as I describe a real-world scenario:
An author publishes a document which requires consent to the system and shares the URI for this document.
A reader accesses this URI and receives a prompt that access requires consent. Consent can be requested by providing one of several communications methods (email address, SMS number, etc.). The reader provides an email address and requests consent.
The system sends a message to the author via a communication method provided by the author when the document was published. The message indicates that this is a consent request for a specific URI and includes metadata about the reader's request that the author can use to decide whether or not they consent to the access. Once the author decides, the reader is notified via the communications method they provided and if consent is granted this message contains a augmented version of the URI that includes a token. This new URI is refereed to as a Consent URI or CURI (pronounced "curry").
If consent was granted, the reader now has 24 hours to access the document via the CURI. If the CURI is accessed after 24 hours have passed, the reader will again be prompted for a communications method to request consent. If the reader provides the same method as before, they will be able to access the document immediately. If not, the author is contacted to provide consent and the cycle begins again.
Why is this better than current approaches?
Consent is an agreement between two people. CBA involve third-parties, it doesn't require the reader to create an account on the system storing the document nor does it delegate this authentication to "yet another system".
Consent must be reaffirmed. Just because it was OK for the reader to access the document now doesn't mean it will be OK tomorrow. It can also be revoked immediately if the Author deems it necessary.
Consent cannot be delegated. CURI's can be shared, but can only be used by others if the details of the readers communication method are shared as well. This requires a significant amount of trust and discourages sharing with just anyone.
CBA respects privacy. The only communications information "permanently" stored in the system is the Author's, and even this is deleted if the document is removed. Readers communication information is stored only long enough to send the consent response (24 hours max), after that it is deleted. Anywhere else a reader's communications information is needed (for example, accessing the CURI) a cryptographic hash of the data is used instead. Passwords are never used, let alone stored.
The idea for CBA came to me when thinking about ways to continue publishing things on the web and sharing links that are accessible by people but resistant to unwanted advances in web scraping for the purpose of training LLM's. There's been a few attempts at this, but all of the ones I've seen rely on either client-side programmatic things that only work in certain browsers or delegating the task to some (usually private, corporate) third party. The blunt solution is to make the resources "private" but that requires either creating a new authority yourself (and requiring readers to create yet another username and password) or again delegating that authority to and trusting a third party,
CBA does away with authentication and focuses only on authorization and to the best of my knowledge is the only mechanism that does this. By doing so it provides both the ability to share URL's publicly that are durable as well as protection from access by random traffic. It makes granting access a personal choice between two people, a human-scale operation.
CBA is also fairly easy to implement. I've already started figuring out how to implement it in JSFS, but it could be implemented in other HTTP services as well. I won't try to explain the technical details until I have a real keyboard handy but I'll post a follow-up once I can demonstrate it in JSFS and provide pointers to how it might be implemented in other HTTP-based services.
Jason J. Gullickson, 2026