Hello, everyone. Very warm welcome to everyone from a little mountain village in Switzerland. It's a bit cliche, but it's, nevertheless, it's the place where I live and also work from today. My name is Jost. I'm the product manager of the SRG login. And we are very happy to have received this award. And before we get into the technical stuff and what we use the SRG login and identity for, I want to quickly bring you a bit up to speed about who we are, what we do, et cetera. So SRG has different business units, which you can all see.
Here, throughout Switzerland, it's a service public, which is comparable to, let's say, ARD in Germany or BBC in the UK, Ule in Finland. So a company that is paid for by everyone and also, because of this, serves everyone. And this is what we do in the end. We want to help the Swiss cohesion, the different language regions that we have, German, French, Italian, and Romance, to come together and provide them with good content, being that journalistic stuff, like news or documentaries.
But also, we want to entertain. And our concession says that we have to entertain people.
This is, for example, why we have a streaming service called Play Swiss, where we try to show some Swissness in the program, where we try to bring together people in their different languages. And this product, Play Swiss, is something that was also in our journey with the srg-login, very important kind of the center. It's our big, big product, which we are trying now to make even better, with also the srg-login and the system behind it, and where we really want to show what the cultural variety that Switzerland has, and also inform people via audio and video.
And actually, that's all I want to talk about right now, because I think you are more interested in everything that's behind it. So I would like to hand over to Gabriel and Sadrik here.
Thank you, Jost. You're quickly waiting for it.
Oh, no. Perfect.
So, Dennis. Great, so srg wanted to take the digital user experience to the next level. Historically, user-faced fragmented processes across platforms, TV, streaming, and online portals, which led to friction and inefficiencies. The vision was clear. Introduce a central, secure, and privacy-compliant identity platform. The technology of choice was SIDAS, a leading cloud-based CIAM provider. But to make it work in a complex environment like srg, a strategic implementation partner was needed. That's where Securix came in.
I'll now hand over to Sadrik to give some insights about the migration from Azure B2C to SIDAS, and secondly, the login and registration flows of Swisscom Blue TV. Thanks, Gabriel.
Yes, so we picked out two of the many challenges or tasks that we had during the integration project. One was the migration from the existing customer and access management solution to SIDAS. In particular, we had a really important topic that we didn't want to re-authenticate the users. So that implied, in particular, two challenges here. First of all, users use passwords. So we need to migrate the password hashes. Since we didn't get the chance to get the password hashes, to migrate them, we had to use a different approach for that. We're getting into closer on that right after.
And second, users who are already logged in, so as outlined by Joost already, there are mobile apps, TV applications, and all that. So users are already authenticated in the online services, be it a mobile app, the TV, or whatever. We didn't want them to be logged out and logged in or re-authenticated again there. So there are two challenges which we need to address during the migration. First thing is, how could we migrate the password hashes? We don't have them available. We started in step one. User accesses SIDAS or authenticates against SIDAS. And SIDAS calls the APIs of Azure AD B2C.
So we had the possibility to redirect or forward or call the authentication APIs of Azure AD B2C. Azure AD B2C could confirm if it's a correct password or not. So we did a normal authentication with SIDAS as proxy in between. Once we got the confirmation, we were able to hash the password, what we got in, and save the password. So we had basically an on-the-fly migration of the user data, or in particular, of the password hashes. One big issue, which then results out of that, if users don't authenticate again, you don't have the passwords available there.
So basically, you have a transition period of a certain time. And you will not run that until all users are migrated. But at one point of the time, you will shut it down. So you will decide, OK, whatever, after a few weeks, months, years, whatever, you need to decide to shut down the migration process and establish for users who didn't migrate or didn't re-authenticate during the whole process, how do you migrate these?
For these, we had a separate process in place. So users who didn't have a password, since we at CDoS also allow password authentication, we allowed an OTP-based flow. So you enter your email with an identifier first approach. We recognize if there is some password available or not. If no password is available, we'll send an email to the user. User can authenticate once with an email code. And then in the step of this authentication, set a new password, basically. So we really also have a transition period for users who do not have a password, migrated since they didn't re-authenticate here.
A second task is, in particular, the migration of a refresh token so that users stay in. Obviously, we at CDoS also have the refresh tokens and all available. And we also allow to migrate existing refresh tokens into CDoS to allow then also keeping the users in the sessions alive and do not force users to re-authenticate.
So that's, in particular, the challenge regarding the migration and re-authentication topics. And second was one important topic. In Switzerland, there's the Swisscom Blue TV. Some of you might know that if you're from Switzerland, it's basically a TV box which you can get there. In different other countries, you have other solutions there. And as you just outlined, Blazor is one important service. You basically have the option in Switzerland, if you have the TV box of Swisscom available, you can download or use the Blazor app.
And based on that, you do not need to authenticate directly to the Blazor services or to the SSG login. But you can use the Swisscom Blue TV as an identity provider. So basically, we integrated Swisscom Blue TV based on a device code flow.
So we really have a device authentication of the TV box to CDAS or from CDAS to the TV box and to the Swisscom services behind and can thereby have the Swisscom identity provider connected and allow a really local authentication or device-based authentication at the TV set top box and really allow frictionless and convenient login, also integrated with other identity or authentication providers. So far, two of the main obstacles, challenges.
Obviously, there were much more, but just to spotlight two of the main challenges what we had during a migration project here. Thanks a lot for your insights, Cedric. So let's have a look at the project approach and collaboration. Our role at Securix extended well beyond technical setup. We acted as a strategic and technical translator, connecting SRGs, business, legal, IT, UX, needs with CDAS capabilities. We worked in agile sprints, enabling quick feedback while ensuring architectural stability.
We co-designed the user journey, defined the security setup, and including MFA and consent and managed expectation across departments. Oh, no, it works. Sorry. Together with CDAS, we tackled device-based logins for smart TVs, verification flows, and even developed family and group account sharing. This was not just implementation. This was kind of a co-innovation. Cedric will now give you some insights about these flows.
Yes, I think one important thing, which is in particular on the roadmap, in the SRG use case, we all know the issue of the account sharing topics, which many of the big streaming service providers now tackle and force users to detect different devices which are already authenticated so that there's no account sharing happening. And I think one big issue with the account sharing is not that accounts are shared, but it's not in a user-friendly way how we expect it.
So I think no one here would claim an issue if they properly could manage their users and devices within their family or friends' account. But today, it's just possible to share the password, and then you can re-authenticate again on a new device, but there's no really user-targeted or user-identity-separating approach on that. What we offer with CDAS, and which is on the roadmap in the SRG use case, is to have these group-sharing capabilities available.
So you can build up groups of family and friends who jointly have an account there, but the users are really separated and can authenticate on their devices, be it a TV, be it a mobile device, be it any online service, which they authenticate themselves, really have separate accounts there or identities there which are connected to one streaming service account in that backend. And that enables also for certain business use cases.
So if a family is there, the children want to watch a movie, and they click on a movie which is only allowed 16 or 18 years old, they cannot access that because their account doesn't allow that. But what they can do is they can request access to that TV because they can basically do an authorization request and say, okay, the parents are not at home, we want to watch that movie, click on that, and then you get a pop-up saying, okay, I want to watch a movie, request access or request to view that to the parents or abort.
And if they request that, the parents can receive a push notification, whatever in their mobile, play a Swiss app and say, okay, yes, I want to watch that, or no, I don't want to allow the children to watch that, and then proceed there.
So in that use case, we really then have the advantage of the account sharing, group sharing capabilities there where you have single accounts, and based on this identity approach, you can also enable new business use cases where you allow users to request authorization on certain scenarios like in the streaming service use case where they can request to watch a movie which they are technically or business-wise not allowed to watch, but parents would be able to allow that.
So, and that's one thing which is on the agenda for SHE to really improve there and bring new capabilities, new features which show innovation and user-friendliness in a quite new way in the streaming service area. So, what you just heard, the outcome is a secure, seamless and scalable identity platform. One login across all SRG services, password-less authentication, Swiss mobile number-based verification for localized trust, and last but not least, full compliance with Swiss and European privacy laws. The success of this project reflects the value of our approach.
As Securix, we don't just implement, we shape the digital identity strategies. In CIM projects with CITAS, we bring real-world experience, privacy by design expertise, and strong alignment with both the technology provider and the customer. This is how we deliver long-term value to enable a safe digital world.
So, also to give a short summary from our side, we're really happy about the project, to have a great partner with us in the project, to have a great project and customer who really have innovation or are really open for new innovations, not just the classic login capabilities, but also looking forward on how we can use group-sharing capabilities, things like this authorization request scenarios and things like that.
There were challenges during the project, like the migration without re-authentication and the creation of specific authentication identity providers like the Swisscom Blue TV Box, but we were able to manage them in a good way. Both FCIG, Securix, and CITAS lead the project to success, and we're really happy that the project was a success. We have won the EIC award, and also that you joined our today's presentation. Thank you. Thank you.
Thank you very much for this presentation and the insights, and I think now this goes along that like the things we know from the enterprise, IEM and so on, now spawns also in the reality of the customers. So my question to the audience, any questions that you want to raise to our experts here? Anything you want to ask or to get to know better?
Otherwise, I have a question. I was also in other companies also saw this migration without interacting with the user. My question is, how did it really work out that way that the user was not aware that you're changing the tool behind it? So did you foresee all the obstacles that come, or was there something like, you know, you're changing the tool behind it, like there is the user, yeah, and who is very curious and finding new ways to do things different.
Were there any obstacles where you were surprised that, okay, that we did not foresee, or was it like that you could really foresee everything because, yeah, well-planned and a limited scope? Yeah, I think two things here. So I think we could foresee most of the things. That's also because of the experience we had in the three parties involved in doing such things. So obstacles, I wouldn't say are a big thing, but users recognize it, because normally if you do a migration, you use that to also introduce new things. For example, in an easy way, the user interface has changed.
So you're locking your eye changes, so there you at least detect something changed. So you really have the capability to change a few things, and that's also what was done here. So a few things were changed, and in that process, you also add new features. So a user will detect that there's a difference, but important is not that there is a difference or a change, but important is that you don't have obstacles or challenges for the user, and I think that worked out pretty well. You want to add something?
I think it's perfect what Cedric just mentioned, and, yeah, one of the key success factors was to make sure that we have a smooth migration from Azure B2C data to the new identity platform, Okay, perfect. Ben, thank you very much for these insights and...