Separation of concerns between controllers and processors underlies most new privacy regulations as well as Zero Trust Architecture security. A protocol connects a controller to a processor. Standardizing this protocol is essential to enable independent development and regulation of controllers and processors which, in turn, promotes innovation and competition.
Self-Sovereign Identity (SSI) standards inform the design of the protocol between controllers and processors that enable authentication, authorization, and audit of transactions. The actors on the controller or processor sides can be either self-sovereign, fiduciary, or institutional. A self-sovereign actor does not have any privacy policy or related governance constraints. A fiduciary actor is subject to some jurisdictional or institutional constraints. An institutional actor (e.g. corporation or government) is not designed to put the needs of the individual before their own.
The ability to choose one’s fiduciaries (e.g. doctor, lawyer) is core to human rights that mitigate the asymmetry of power between individuals and institutions. Therefore, standards that enable an individual to choose a fiduciary independently of the institutions they face are a matter of human rights. Self-sovereign individuals may also have a right to represent themselves and forego the fiduciary as an intermediary.
API Neutrality is achieved when the protocol that connects controllers to processors is agnostic to whether the controller is self-sovereign or fiduciary. (Examples of the converse, where an institution is the controller and the processor can be either self-sovereign or fiduciary, are rare.)
Regulation of controllers as fiduciaries is difficult but standards can help avoid complex regulations. Institutions, including the global platforms and data brokers are loath to separate their roles as both controller and processor. API Neutrality is a relatively simple thing to understand, voluntarily self-assert by institutions that adopt it, and potentially to regulate for institutions that hesitate, but it requires the protocol standard to be compatible with self-sovereign operators in order to keep the would-be fiduciaries honest.
Like SSI, API Neutrality can be considered another human right. As we discuss authorization and audit protocols for access to Confidential Storage, I hope we can build on a foundation of self-sovereign individuals as resource owners and requesting parties and their right to delegate to self-sovereign data controller agents, self-sovereign user agents, and self-sovereign clients.
Specifically, Confidential Storage protocols must not presume that the storage entity (a processor) is also controlled by the same entity. The OAuth2 presumption of combined resource and authorization server control is an anti-pattern.
Given that our charter specifies: “Focus on an HTTP-based interface for the API mechanism.”:
Proposal 2 - The HTTP-based interface for the API should use GNAP or another protocol that does not presume that any of the RS or AS or RC are controlled by the same entity.
Separation of concerns between controllers and processors underlies most new privacy regulations as well as Zero Trust Architecture security. A protocol connects a controller to a processor. Standardizing this protocol is essential to enable independent development and regulation of controllers and processors which, in turn, promotes innovation and competition.
Self-Sovereign Identity (SSI) standards inform the design of the protocol between controllers and processors that enable authentication, authorization, and audit of transactions. The actors on the controller or processor sides can be either self-sovereign, fiduciary, or institutional. A self-sovereign actor does not have any privacy policy or related governance constraints. A fiduciary actor is subject to some jurisdictional or institutional constraints. An institutional actor (e.g. corporation or government) is not designed to put the needs of the individual before their own.
The ability to choose one’s fiduciaries (e.g. doctor, lawyer) is core to human rights that mitigate the asymmetry of power between individuals and institutions. Therefore, standards that enable an individual to choose a fiduciary independently of the institutions they face are a matter of human rights. Self-sovereign individuals may also have a right to represent themselves and forego the fiduciary as an intermediary.
API Neutrality is achieved when the protocol that connects controllers to processors is agnostic to whether the controller is self-sovereign or fiduciary. (Examples of the converse, where an institution is the controller and the processor can be either self-sovereign or fiduciary, are rare.)
Regulation of controllers as fiduciaries is difficult but standards can help avoid complex regulations. Institutions, including the global platforms and data brokers are loath to separate their roles as both controller and processor. API Neutrality is a relatively simple thing to understand, voluntarily self-assert by institutions that adopt it, and potentially to regulate for institutions that hesitate, but it requires the protocol standard to be compatible with self-sovereign operators in order to keep the would-be fiduciaries honest.
Like SSI, API Neutrality can be considered another human right. As we discuss authorization and audit protocols for access to Confidential Storage, I hope we can build on a foundation of self-sovereign individuals as resource owners and requesting parties and their right to delegate to self-sovereign data controller agents, self-sovereign user agents, and self-sovereign clients.
Specifically, Confidential Storage protocols must not presume that the storage entity (a processor) is also controlled by the same entity. The OAuth2 presumption of combined resource and authorization server control is an anti-pattern.
Given that our charter specifies: “Focus on an HTTP-based interface for the API mechanism.”:
Proposal 1 - Adopt the terminology for RS, AS, RC, RQ, and RO as defined in https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/?include_text=1.
Proposal 2 - The HTTP-based interface for the API should use GNAP or another protocol that does not presume that any of the RS or AS or RC are controlled by the same entity.