What is great with @Identiverse is that you keep digesting everything you learn (and re-learn) during 4 crazy days of first class, deep, and detailed materials on Digital Identity, Trust, and Privacy. This year was once again no exception for sure. The planning was packed with food for the thoughts and for the bodies too thanks to the traditional bootcamp.
Thanks to Brian Campbell aka @__b_c for all the photos !
So the schedule was intense and it was a dilemma to choose between all the tracks at some point. So find the recaps of any attendee, consolidate them, watch the Youtube channel for the session recordings, and next year contribute to the pot by attending. For my part, I used my notes and some analytics I ran on the #identiverse hashtag through a GraphDB. I will explain the how in a latter post for the one interested.
I take a small break to make some advertisement for the OpenID Foundation. For 25$, you can join it, deep dive within today protocols' RFCs by asking the Pros behind it, contribute to workgroups for corrections/precisions/details on current protocols' flows, and vote for tomorrow protocols' specifications.
The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. The OpenID Foundation is a non-profit international standardization organization of individuals and companies committed to enabling, promoting and protecting OpenID technologies. Formed in June 2007, the foundation serves as a public trust organization representing the open community of developers, vendors, and users. OIDF assists the community by providing needed infrastructure and help in promoting and supporting expanded adoption of OpenID. This entails managing intellectual property and brand marks as well as fostering viral growth and global participation in the proliferation of OpenID.
The client in OAuth is any piece of software that needs to access to the resource... it is not necessarily running in the browser. I can be an applicative backend.
API Keys don't allow to understand the user a client acts on behalf of... for example: do you think Google will give a key to one client to access all the resources of Amazon?
This session was core the next sessions of @justin__richer‏ on everything that is bad with OAuth and the presentations on protecting the API by @bertrandcarlier‏ and @prabath.
In this example, the Resolver will implement the Authorization logic based on the OAuth and the relationships between the clients, the resources, etc.
The best way to start with development around Graph technologies is by using grandstack.io.
After that, I joined Nat Sakimura aka @_nat_en, the chairman of the OpenID Foundation in a deep dive within Financial grade API or FAPI.
FAPI is now extending from UK and Japan to Australia.
FAPI introduces Sender Constrained Token that can be bound a token to a specific User Agent for which it has been issued. There is also another scenario with Client initiated Backchannel Authentication or CIBA that solves use cases where authentication is happening through another channel... I will need to deep dive more in that in a following post.
Then I went to the sessions for API protection best practices by @bertrandcarlier‏ and @prabath. @bertrandcarlier‏ can be seen on his SlideShare.
The main issue is that the monolithic sub components do not fear from where the request came from and share a session store... this does not apply to microservices architecture... leading to greater attack surface.
Overall, I learn the notion of micro-gateway / micro-PDP. This is a change from the usual architecture as the decision is always taken locally preventing latency. Stress is now on the replications of policies from a central point (PIP?). From we must try to propagate the identity of all the tokens the request relied on during the components to components micro-exchanges.
To ensure that the identity of the components is correctly bootstrapped @prabath presented the SPIFFE/SPIRE framework. I will need to deep dive more in that in a following post.