diff --git a/public/images/google_token.png b/public/images/google_token.png
new file mode 100644
index 0000000..c37a543
Binary files /dev/null and b/public/images/google_token.png differ
diff --git a/public/images/idp_login.png b/public/images/idp_login.png
new file mode 100644
index 0000000..daba7ff
Binary files /dev/null and b/public/images/idp_login.png differ
diff --git a/slides.md b/slides.md
index c88fe90..b62f46f 100644
--- a/slides.md
+++ b/slides.md
@@ -65,21 +65,21 @@ color: gray-light
+ 
- 
- 
- 
-
+
+
+
@@ -174,7 +174,7 @@ It’s about **files**: placing, replicating, removing files
- **LFNs** are registered in *catalog(s)*
- where are the LFNs? (in the DIRAC File Catalog (DFC), or in Rucio)
- what are their metadata? (in the DFC, or in the LHCb Bookkeeping, or in AMGA)
-- LFNs *may* have **PFNs**, stored in **SEs**, that can be accessed with several protocols.
+- LFNs *may* have **PFNs** (physincal file names), stored in **SEs** (Storage Elements), that can be accessed with several protocols.
:: content ::
@@ -273,6 +273,66 @@ DIRAC also provides a WebApp:
Implemented using `ExtJS`, and fully custom Python "bindings"
+---
+layout: top-title-two-cols
+align: c-lm-lm
+color: gray-light
+title: world
+---
+
+
+What is the best way to achieve that? Can we do it within the current framework?
+
+
+
+:: title ::
+
+# Few topics of interest from the technology world around us
+
+:: left ::
+
+## tech trends
+
+- You authenticate with an external "Identity provider":
+
+
+
+- For authorization purposes you are using tokens everywhere:
+
+
+
+- (Nicely documented) REST APIs are a de-facto standard:
+
+```sh
+# "get a tag" from github
+
+curl -L \
+ -H "Accept: application/vnd.github+json" \
+ -H "Authorization: Bearer " \
+ -H "X-GitHub-Api-Version: 2022-11-28" \
+ https://api.github.com/repos/OWNER/REPO/git/tags/TAG_SHA
+```
+
+:: right ::
+
+## WLCG, EGI
+
+**Community management**
+- VOMS (Virtual Organization Membership Service) has been, for many years, a de-facto standard
+ - it issues VOMS proxies ("short" certificates)
+ - Outside of WLCG and EGI, proxies are not a thing
+- There are new Identity Providers delivering tokens instead of proxies
+
+In this conference:
+
+WLCG transition from X.509 to Tokens: Progress and Outlook
+CMS Token Transition
+
+Fermilab’s Transition to Token Authentication
+
+
+
+
---
layout: side-title
@@ -298,7 +358,7 @@ title: issues
Old monitoring
- “old”-ish design (RPC, "cron" agents…)
+ "old"-ish design (RPC, "cron" agents...)
not very developer-friendly: rather un-appealing/confusing, especially for new (and young) developers
multi-VO, but was not designed to do so since the beginning
no clear interface to a running DIRAC instance
@@ -357,7 +417,7 @@ side: left
color: gray-light
titlewidth: is-5
align: rm-lm
-title: DiraX
+title: DiracX
---
:: title ::
@@ -369,7 +429,10 @@ title: DiraX
- A cloud native app
- Multi-VO from the get-go
- Standards-based
-- Still DIRAC, in terms of functionalities
+
+
+Still DIRAC, in terms of functionalities.
+
---
@@ -869,12 +932,10 @@ title: summary
:: right ::
### DiracX is in active development
-- It will live together with DIRAC v9 for a while
- Foundations are there, the first release will soon be here
-- We plan to ease the interoperability with Rucio
- - DiracX will still have the Data Management part, but WMS will come first
-- In October 2023 the DIRAC consortium members approved DiracX recommending a smooth transition from DIRAC
-
+- DiracX will live together with DIRAC v9 for a while
+- DiracX will ease the interoperability with Rucio and/or any other tool out there
+ - DiracX will still have the Data Management part, but its Workload Management functionalities will come first
---