Decentralizing OAuth2.0 in a post-GDPR world for full privacy and portability
Automating, API-fying and Tokenizing GDPR for privacy and portability with open source software
- Track: Decentralized Internet and Privacy devroom
- Room: UA2.220 (Guillissen)
- Day: Sunday
- Start: 16:00
- End: 16:30
Users want their data back and the ability to transfer them the way they want to the platform they want. This si user's freedom in a digital world. Today, because of current authorization protocols/framework design like OAuth2.0, power is concentrated to the identity providers who decide what applications they allow to access their API and the user cannot say anything about it. New regulations like GDPR have appeared to enforce this freedom for users by law but there is not yet tooling for developers to make GDPR data ownership and GDPR data portability happen, useful for users to avoid this To really decentralize data permissions from platforms control, make users in control of their privacy and make companies GDPR compliant, you need now to update OAuth2.0 dance into a stateless flow and tokenize the GDPR authorization and agreements to make it programmable for developers. In this talk, Mehdi will explain how you can use open source technologies to automate GDPR requests for your users to, build APIs on top of GDPR takeouts, export GDPR user 3rd-party data in your system and tokenize your GDPR agreements to make them programmable for compliance using opens source technologies.
Making GDPR programmable and adding decentralization of data portability to OAuth2.0
In the classic OAuth 2.0 flows, the authorization server and the resource server are behind the same firewall, giving full power and control about sharing capabilities to the Identity Provider (i.e. Facebook, Amazon, Google etc...). The Identity Provider decides what can be shared to whom via its API, and the user is limited into making data exportable to what the Identity provider allows. Because of new regulations about data portability (GDPR in Europe and CCPA in California), now every user is able to ask a full export of its data to be stored anywhere, breaking Identity Provider monopoly and control. In that context, users can now own fully a copy of their data and share it to who they want. They can now become theoretically independent from previous Identity providers, by becoming their own Identity Provider if they are able to install a server to do so themselves, or theoretically choose the Identity provider that is the best delivering value for them about managing their personal data and permissions. As we seen in Bitcoin, a large majority of users will still want to delegate authorizations to a trusted 3rd-party to manage permissions, as they do until today with banks for their money, or to wallet managers for their Bitcoins/Crytocurrencies. In the Alias protocol ecosystem,users decide where their data is stored (on the server of their choice) and decide the Alias authorization server that will manage its permissions.
Introducing Alias protocol
Alias is a protocol enabling decentralized data export authorizations. When implemented, Alias enables for users to decide to share the data they want, to whom they want, without limitations from any centralized Identity Provider, and in fine grained control. Technically, Alias is a decentralized protocol based on OAuth 2.0, where each user, identified by an cryptographic alias, can let third-parties ("clients") access to their data stored in servers ("resource servers"). Access to the data is controlled by an Authorization server ("authorization servers") that manages permissions and scopes. The main innovation of Alias is that the resource server and the authorization server do not need to be behind the same firewall, enabling users to decide freely and in full control who store their data and who manage permissions in a decentralized way.
Speakers
 |
Mehdi Medjaoui |