Good afternoon, ladies and gentlemen, welcome to our, our call webinar, onboarding your business partners to your services, B2B identity management, or I am in practice. The webinar is supported by I welcome the speakers today are Marcou who is vice president product management at IWE and me Martin equipping or I'm co-founder and principle Analyst at a call before we start and dive into the topic, some quick information about a call and some housekeeping information. A call is an independent global Analyst company with delivering a variety of services, such as executive executive view reports, leadership, composes, webinars, and conferences, but also advisory services around identity and access, cyber security and artificial intelligence. We have a number of different research formats such as, as our leadership compass, where we compare vendors and the offerings and certain market segments or executive views focusing on individual products and services, advice, notes, and leadership briefs for the background information and the information you need for decision support.
In advisory, we support you in creating your strategy, defining your portfolios, selecting the right type of technology. And in some areas of implement of, of running a project, what we don't do is we don't do any implementation work. We just support you on sort of the neutral end, defining your portfolio selecting right technology, cetera. We have various events. We run so currently or upcoming. We have a couple of events around cybersecurity around identity in Berlin. We have an AI went later this year in November, and we have consumer iden consumer identity went, which will run next week in around the week after next week in Amsterdam. So various events coming up, have a look at our website, which events we will have and what we are doing here for the webinar itself. You ARED centrally, we are controlling these features, so you need don't need your mutual on yourself.
We are recording the webinar and we'll make the podcast available short term and also will provide slide X for download. And there will be a Q and a session by the end of the webinar. However, you can end the questions at any time and obviously more questions we received during the webinar. The better it is because we then can have interesting Q and a by the end of the webinar for the agenda today, we split this into three parts. The first part is that we look at the differences between various use cases for managing identities. So from B2 E to B2B, to B2C, and we look at a high level requirements for B2B. That will be the part I will do more as the introductions or the umbrella for topic of this webinar. And the second part, then Marco WITI, I welcome will dive much more into detail and then look at the very detail of B2B IM in practice and how to solve specific challenges.
Best. The third pattern will be our Q and a session. So when we look at the topic of B2B IM I wanna start with what is the drop of IM itself? So what is it why we really need identity and access management? Basically the drop management is connect everyone to every service. And we see that this is to some extent, more coming together, overlapping. So specifically B2 B and B2C. Sometimes it will be to E to B, to B use cases, factually all of these have something and similar and all of these have something which makes them different. And when we talk about everyone and maybe even ever thing to extend, we talk not only about employees or consumers and very important group business partners, which again, have a variety, or we have a variety of different types of business partners, which can be contractors, which can be your suppliers and, and many others.
So there are very different types of business partners with specific requirements on access, and all of these users need access to some of your services, not all, and only controlled the limited access, but they might need access to some of your cloud servers, to some of your services, which are still running on premises, supporting Federation technology, or where you federate out to others and to your legacy applications. So we need to collect this. We also will observe when we look at this more in detail, these have different identity providers, the consumers might come in with their own identity. So bring your own identity. They might rely on external identity providers starting with the social login just as partners might federate in. So when you work with large suppliers, it might be that you build on identity Federation. You might build your own own repositories for partners instances based on an identity API platform.
The employees say employees on the other hand might be still manage in your internal directory services, your active directory, your L lab, whatever, what we clearly sees, that there's a broader number of these IDPs. So it doesn't make it simpler. And then we F it out to the cloud, or we have an API based access. We do it with the applications that support Federation standards. We might use more traditional technologies, such as web single on our APIs to connect to our legacy applications. And we need to build something in between, which provides the access management capabilities, the administration and governance for identities and additional capabilities such as constant privacy, and more from a logic perspective, this is sort of a set of services, which commonly is deployed through multiple tools. So there's not that single tool, but it's a, it's a set of services which enable you to connect all these identities to all these services we at could be a call.
We call this an identity fabric. And so there's more, more research provided by available around this topic. This also relates to when we look at B2B identity and other types of identity management, also to sort of the evolution of identity to do this very, very quickly, we started way ago with managing users per system. We added some identity management, some 25, 30 years ago, maybe sometimes even a little more, but we started synchronizing accounts between systems where we initially had things like meta directory service, stuff like that, and provisioning came into play. But the focus was very much on employee identities. We then had sort of first touchpoint to, to business partners with Federation, which binary primarily was more between bigger business partners. So you have a large supplier, a large automotive vendor here, federated identity, so that you don't need to manage all these employees of the supplier at automotive vendor, stuff like that.
We at the first standard protocols, we also saw these types of technologies and center becoming then adopted by cloud services for single and son. On over the past couple of years, we saw more and more uptake of consumer identity management. So from the BTU E to some B2B, to B to C, and right now we see that this becomes more and more a mixed picture. So where, where we have the same approaches sometimes also bring your own identity or external identity providers, which are shared with see also the, the trend to, to sharing and reusing KYC information. So know your customer to the formal onboarding processes with strong regulatory requirement. So we see this shift and we see also some convergence between such use cases, but we also see the specifics. And when we look at these specifics and I know that Marco will have a, a slide, which also looks at this with a, with some overlap on some extensions.
But if you look at these, these specific identities of these various groups, so we have the consumers, we have the partners, we have the employees, or we have B2C B2B B2, E how do these things look like when we look at consumers and registration, then for consumers, registrations very frequently as self servicing, you notice all from your daily life in the internet. So to speak, when you here is a service, there was a service, unfortunately it is very frequently re-registering again and again. So, so little reuse of identities. This is happening sometimes with specific KYC processes. So when you go to a telco, when you go to a bank or other, then registration needs to comply with registration needs to comply with regulations. And then we are talking about is specific KYC process. We have pretty simple concept of, and big, big quotas here of, of roles or whichever construct you want to use to group consumers.
So there are simple and usually very few different types of bundlings of dial of groups of consumers. You have we say, okay, these kind who do that, or that what you commonly have is sort of an lots Agon aspect, which means that Martin Cooper is only allowed to see his orders, his invoices, and all the other stuff. So that is something where you don't limit it. You say every customer is allowed to see his invoices, but if it, but only his, and so these are things, but the concept is, is relatively simple compared to the complexity we see in the employee employee environment frequently. So deprovisioning for consumers, it honestly rarely happens. So if you somewhere and you don't order goods more from there at sometime, you might be deleted or you trust your, your current trust remains there, but that's it. What is the focus?
The primary focus is really enabling flexible, authentic education, supporting all the different IDPs more and more so, not requiring the people to re-register again for the service, but to work with external IDPs, make it easy, make it simple for partners. It looks fairly different. So the registration is in an ideal world, managed by the business partner, why our Federation. So supplier already has a system where he has his employees in where their roles are in, in some way, what are they doing? And he could fair it out today, authenticate as a business partner and you trust him. And if, if that person still has to drop, you allow him to do certain things. Doesn't work always factually. In many cases, it doesn't work that way. So you might build your own solution for business partners, your own IDP, or you might rely on other types of registration.
Also some self registration stuff, etcetera. This gets more granular because you might not have people from different suppliers of being allowed to different things, because they're depending on the business process, the business relationship, the differ, but it's by far, usually not as sophisticated as it is for employees. When we look at the granularity of entitlement management, one of the big challenges in here is obviously deprovisioning. It must be done by the partner. At least in information has come from the partner, oh, Martin doesn't have to drop anymore. Or Martin doesn't work at my company anymore, which frequently fails, but it's critical capability. So this must work. Well, obviously you could could argue if, if, if the person can't also indicate with the business partner anymore, you know, safe side, but not necessarily because the person might just have a different drop and then you still have a have an issue.
So managing this is clearly one of the interesting things on B2B identity management. So focus enable Federation and ensure proper on, on an offboarding remain flexible in support different scenarios. So I talked about suppliers, but you also have your contractors, contractors are frequently more managed by someone in your organization. So it's a different thing than federating. This business partner. You might also have the need for some low level KYC processes. So, so one of the, the things, when I look at the security people in organization, which frequently are outsourced, in many cases, they always use the same account because there's a lot of change amongst these people. So they're frequently, there are a lot of different people coming in and out, and the process don't work well, but specifically, for something like that, you need to have well working process where everyone is managed properly and has its own identity because it's about security.
So looking at employees again, a different picture, there is registration is frequently automated. Sometimes partially managed happens from the HR system or systems like that. The roles in entitlement models are frequently rather complex and honestly, very, very frequently overly complex. So many organizations make it far too complex. The role models, some pragmatism and some good human sense definitely helps here. So don't, don't make it too complex, but it is more complex than the other areas because you go into far more detail, you have more granularity, a lot of different things to do in your organization. Deprovisioning still commonly cumbersome, commonly less automated as registration, but it obviously is mandatory. So again, something you need to solve focus is increasingly shifting to the access management piece. So beyond trust, managing the entitlements and reviewing the entitlements, how can you give your employees a convenient access? So for consumers tends tendency is self-service partners delegated easier to the partner or to someone in your organization. Sometimes also self-service so it's wild mix. So it might be managed delegated self-service for the partner while employees and consumers usually have a very clear approach E self service or manage, but there are also are similarities. What is common across all?
We are talking about identities and accounts. These identities are converging and identity management are also converging. So we see more overlap between the use cases enable access of everyone. Like I've already told in a, to everything in, in a controlled manner, we need to look at privacy and consent. In each of these cases, GDPR applies to everyone. Contracts might help for employees, probably will for partners, they might help or not, but it must not be. Or we must look at it. Delegation is something we have. So managers, manager, team members, project manager, manager, the me members of the project team partners, manager, employees, sales team might manage customers. Customers might manage family or team members. So we have a need for delegation. And that is something which is, I would say one of the, not that well solved areas in most, I am solutions these days, but in some its wide well solved and we have authentication authorization at the end. It's all about access. You need to manage access. Well, that is the essential thing here.
What are the main requirements for doing B2B IM right. So sync beyond B2B. So I think you shouldn't end up, I know I recommend, I'm convinced you shouldn't end up with a B2, B identity management, a B2C identity management and a B2 E identity management, all separate from each other. That doesn't make sense. It's looking at all areas of finance management. It's far more than, than IGA or so. It's Pam it's identity Federation and other stuff. So look at it from what, what all does it need to do it right? Having the access focus, focus on access management, but also access governance. So control access at the end, that is the important thing to manage. Be flexible regarding the models. There are multiple models for service service for delegation, specifically around partners. And specifically for this area for B2B anti management, you need to cover a broad range of approaches because there's not the one partner and finally do comprehensive. It's easy to onboard someone it's more complex to onboard define the processs that both their organizational level and the individual level. Well, so avoid risks by spending time on processes. That is so from my end, the overview of what I think is very important for a well working B2B identity management, which is more of than just B2B identity management, which always needs B2B part of your overall identity management approach. With that, let me hand over to Marco right now will go more in detail to talk about very details in practice, Marco, it's your term.
Thank you very much, Martin. And thank you all for joining us today. And in the next 20 or 25 minutes, I would like to go through a very short agenda for today, which is a bit of an interim recap of previous episodes that we shared before around the similar subject. And then to share some case studies, some real world scenario that we had the opportunity to address over the last couple of years, trying to identify commonality and diversity, and then look at what was the approach in terms of solution case study in of design. And that lead Q, as I said, this is the second of the conversation that started back in may around similar subject, which is B2B and B2C. And I'm assuming for the purpose of today's conversation, that most of you haven't attended that session. So to some extent, a few slides will be a repetition apologies for those who actually attended that before.
But again, it was back in may, so it's already five months ago, but again, the subject is so broad. There are so many things to share that we decided to split what we have to, to say and what we would like to share with you into two different episodes. So for today's session, the key question that I would like to address are really about what are the typical scenario like? So what defines B2B? Why is that different? What kind of challenge is that defined by and what are the core needs in terms of technology and talking technology, which adoption have you assisted over time? So hopefully this is meaningful for you. And again, picking back from what Martin just introduced in this very nice light around the distinction between workforce B2B and B2C. I would like again, to extend from that, introducing what I call the identity S that we assist these days, because again, we have workforce identity, which has been there for a while now and is definitely served by well-established solution already.
Opposed on the opposite side of the spectrum, we have the consumer one much more recent, but still, also, yeah, also very well defined and this in between space, which depending on the specific case is closer to the workforce. One or more often to the consumer one in terms of needs, but all in all, it means what, what this means is that we still have this days, a very clear distinction between pure workforce or consumer solution out there in terms of market offering. But at the same time, there is no such a thing as a single solution that span thoroughly the entire spectrum. So you cannot just pick a single product, expecting it to be able to properly tackle the workforce all the way to the consumer use cases. And that's not a big problem if it wasn't that hybrid or in between scenario are increasingly frequent, if not the normal rating.
So that defined what I call a, an interesting mix of mix and combination of, of statement. Because again, it pose a challenge, a challenge about picking the right solution for the job, depending on the use cases you need. So when is usually B2B identity management involved. So what are the circumstances in terms of business context that define B2B? So first of all, is whenever we add the pleasure to address a customer where the identity are now originated into an HR. So they are beyond what I call the HR demarcation line. They manage people which are coming from other sources, but definitely not from an HR system maybe. And very often they are in, in a, in a transition, they are rebuilding or replacing one of the core business, one of the core application to manage their, their core business, maybe because they are in the transition as well from on-prem and cloud, that becomes part of it.
And we, they enter a conversation, which is more of an architectural conversation because what they are looking for is, I mean, the business application they want to rebuild is not coming as a prepack application from one vendor out there. There is no such a thing as a preta solution for this, but they need to build it, or at least to customize significantly an existing solution. So again, it becomes very much an architectural conversation, which brings to the quest for the right combination, the right shade of meat versus buy of the various components. Now, part of that architecture, of course, to avoid, to reinvent any of the wheels that are building the entire, the entire machine. So that is bit of a context on when B2B kicks in, okay, most important. One of course, treating identity, which are not coming from the HR. So let's look at a few example of customers anonymized here that we had the pleasure to address in Europe over the last couple of years.
So case number one is from Germany, the manufacturing company, they build equipment, they build machines in the food and beverage segment, such as vending machine, for instance, and they have a large network of reseller distributors and field services company. They have a business relationship with for obvious reasons. The business need they have is to manage the access delegation on the entire distribution and service chain for, for billing the, the, for the billing associated to the machine operation and for the maintenance reasons, in terms of technical requirement, they need to manage flexibility, the course grain and fine grain authorization on user device device as well. We involved here. So there's an I T dimension in this customer case, but, but, but that's beyond the purpose of today's conversation. It really was around managing course grain, meaning USU get access to what and fine grain, which was also about which device should be visible to whom, okay.
That was the combination of challenges they were looking at. Another interesting case is from a banking sector. In this case in Italy is a mid-size bank that was starting a new initiative on the real estate market, selling mortgages and insurance contracts specifically for, for the real estate, but in a pure B2B approach, they don't address directly the retail customer. They just onboard and manage the relationship with dealers, actually in a two-prong approach. Some dealers are onboarded directly by, by the main bank. Some others are coming in through partner banks, banks, not belonging to the same group, but still belonging to the same market offering. So in that case, they need to manage the, the delegation piece, but also the consent related to these onboarding processes, while still retaining centrally, the ability to tweak what is the level of access delivered through the, to, to those dealers downstream, technically speaking, they need to have, they needed to have an identity central identity repository for, for again, identity and access and the course grain and, and consent.
Let's look at the third example, different industry, different countries, still in Europe, but it's time in insurance company, fairly large, one with a full spectrum of product ranging from life, car, home damages, et cetera, and addressing both business and retail customer. And as Barry often is the case for insurance company with wide network of agents and brokers. In this case, the business need was to totally AF upload the access management piece to the broker and to the agents. Technically speaking, they were really open for introducing a sustainable single sign on across the multitude significant number of application they need to provide to those party and to out rise differently. Of course, grain again, the various types of users. So those are just scenario of existing customer, which are by definition very much B2B, or if not purely B2B, but it's also the case more and more that we assist to customers, which are not yet our customer coming to us with every fine fee with more frequently than before our featuring requirements around managing multiple layers of users, different types of users to dedicated registration processes and validation mechanism.
So those are very much the signature of what B2B is about these days. That's where the significant part of the requirement or lending I'm keeping it course grain here. Okay. But we can get to a much more finer grain set of requirement in that space. So in general, what are the key things that I can derive from what I just shared with you in terms of use in terms of scenario, feels like that the most common problem are of course, and that's the very traditional one around what to around improving what otherwise is a fragmented online experience, providing single sign on and removing the need of for traditional multiple password required to get in and providing at the same time is also true for identity and access. But then there is an increasing request for having a central ledger for consent and preferences, because again, employees of other companies, such as business partner are, are not bound to the same level of contract that employees are subject to, which means that they need to express their consent.
Okay. Which is not the case usually for employees. And finally there is the management overloading piece. So how do I offload the overwhelming effort of managing who can do what on those companies that I'm now working with? How do I make that decentralized? So those are really the common problems. So from traditional aspects, such as providing single sign on to delegation, I would call it delegation of authority, not to confuse delegation as I go early. And I want to delegate my colleague. So this is delegation of authority that we're talking about here. That being said, when it comes to build and look at this architecture again is very often an architectural conversation. What are the core components, the wheels that we don't want to reinvent okay. That are defining the architecture when it comes to the identity side of the solution. Well, trying to enumerate the core bullets that defines that the core wheels, the first one is for sure the core identity capability, which have to do with, with authentication Federation, single sign on that, where protocol compliance is also in, right, the Sam, the IDC, well, nobody's really reinventing their wheel, right?
There's such a broad market offering out there of both on-prem or a cloud solution with an API only, or an API plus UI strategy that most of the customer and the pleasure to work with that really getting one of those solutions rather than rebuilding it themself. Okay. I think I hardly have assisted to anybody venturing in that space because it's overwhelming to keep up with the constantly evolving standard. And again, you need to really have a very solid business case to, to go there. Second ballet, a bit more interesting, which is the interaction orchestration. That's where the registration, the validation, the activation process flows are. And also the consent life cycle management and preference management. That's where the, the diversity is peaking. Really one customer is, is not really looking like another one at all. Right? And you have also other aspects that are kicking in such as multi-brand okay.
Meaning the same customer, having different skins, depending on the business line. Now, the, the, in this very aspect around interaction orchestration, there is a big distinction between B2B and B2C because in business to consumer, usually you have a very level of attention on the brand identity. You want a so-called pixel perfect rendering on the way you represent your company out there to consumer, which leads most of the time to custom UI building. You start from the API and you build the UI, leveraging those API to serve the identity needs. B2B is different. You have not the same sense of perfection, okay. In terms of representing the brand identity, which means that you are very open, much more open in leveraging existing built in user, out of the box user interfaces, user experience for business users. And that goes without saying significantly speeds up the time to value that you can get out of a solution.
So for that reason, the inclination of going by versus going API first is very high. Okay. In, in interaction orchestration, third domain, authorization management and authority, delegation of authority. Okay. Those two things could well be and should probably be two separate ballots. I combine them into a single one because to some extent they're addressed pretty much the same way in my experience. Although they're different thing. Again, authorization is around relying course grain authorization on application. Okay. So it's about not necessarily identity specific, it's really business application specific while delegation of authorities around managing other people access and managing other people to become themselves manager of other people. So downstream chains of delegation, right? Those two things are very much B2B related. And again, you find in market solution rather than building them announcer, which is significant to improving your ability to reach an optimal time to value, right on the opposite side of the spectrum to conclude my ration here is the fine grain organization management, which is very much in the guts of the very specific business application.
The company we had the pleasure to work with we're building and is very hard to abstract. And that's where we need to draw the line and to have a conversation with our customer, to understand where we stop with the course grain and where the fine grain kicks in. Okay, fine. Grain can be time served with authorization service technology. But very often, again, it's just built in, into the application. They are now building. So that being said, maybe let's have a quick look in a visual fashion of one of those use cases I've taken the insurance one, which was the third I presented before in the way looked. So in that case, again, it was one company group actually made of two legal entities. One is proper insurance. The one, another one is road assistance service. And the insurance one is representing itself to the consumer with different brands, different skin, okay.
Along the line of different products. This intro group is a fictional name, right? To anonymize the use case, but it reflects reality in this customer. We had the pleasure to serve. So what they were having, again, according to the way we deploy the solution was, well, we look at these two company as to different, by all means domains. So they should treat user differently. So the same person should register independently. If they join one of the three brands of the insurance, or if they join road Del, okay. Of course, between the two, the two groups, there are, there's a Federation in place, but they are registering independently. And apart from that, you want to, in this case, again, serve both the consumer with different brands and there might be different experiences associated to the different brands. We look at that in a minute. And of course we have business users, which are provided with a totally different set of capability, goes without saying specifically the access to the various business application they need to have, and the delegated of the, a delegation capability.
So let's have a look of what it looks like in terms of, well, I level architecture. So consumer rather than going straight into the Porwal of the, of the two of the two companies are provided with dedicated experience for registration authentication and consent. Okay. We don't go there because this is B2C. And today we talk just B2B. Okay. But as I said before, I use cases where you have at the same time, consumer and business user are increasingly frequent, but today we stick with the B B side of the, of the conversation. So let's go to business users where before we're going into the various application directly, maybe without single sign on, maybe with different accounts. And now they are provided with a seamless experience with multiple application bound, into a single view where they can pick the one they need to get to. And they are provided not just with single sign on, but also with course grain authorization, should the target application require that, but where things are interesting is that, that what you provide in that unified view, we are referred as my app is controlled, not by an administrator by, but rather by another business user, which is provided with a dedicated view in terms of managing other people access.
So is man is an experience build for business people around managing other business people and empowering, potentially more delegate, more delegates, not just more business users. So again, implementing a sort of chain of delegation, often referred as multilevel delegation, just to complete the picture. There are some power users involved. We do consider the service desk, the service center reps, power user, because they can do usually more than what others can do. And of course the, the administrator, okay, you see here a number of green boxes, this is a logical architecture. It doesn't mean that our different solution, different component are just the different constituents in terms of capability that are painting the entire picture. So just to provide you again, more clarity around what diversity involves in representing those different kind of scenario here, I capture what is like to address consumer in the various brands and opposed to how is to address business user in that case, right?
So you can see that there are differences, differences on a, a per brand or a per user type in the way you register the user, which extra attributes are required. For instance, if I talk of insurance, a car insurance company, I need attributes that I don't need as a business user. I might offer social registration to consumer, not really to business users. And again, what is this formal authentication is also is also different for instance, to business user that require the second factor now for the purpose of this conversation. And we talk business user, I will close my, my case study digging a bit more in what is like the registration process. As I said before, this is very often the peak of diversity that we assist. So this is a business line with the busy picture, which of course am not going through. What I want, like, just to leave you with is that usually we need to use pre defined simple of processes that we we have or to customize, or to build new one.
But in general, you always land into three, three aspects that need to be covered. There is an identification and consent initial part, where you find what you define, who is the people you are, the person you're dealing with and what the consent about. Then there is a validation of that identity and a profiling, and then the preparation for implementing some sort of second factor authentication when required. So let's zoom quickly in a bit more detail on the top. Part of it in this case is, was very much about just capturing the email address of this business partner now registering. And again is consent on document and on attribute, email per se is a very shallow form validation. But at times there are form of restriction of the email domain accepted to at least make it more valuable in terms of value of the attribute email address per se.
But of course it's not enough, right? We're talking business user. We will never be giving access to somebody just because he has a valid email address. So in that case, there was a double validation. One we're talking, you have a Dutch company. So in that case, it was leveraged the banking industry E ID, which is IDing for those of you are not familiar with. Okay. So there was a, a branch out to IDing to validate the, the identity out of the email provided. Okay. But then after that phase, there is second validation on the various attributes in a lookup of one of the legacy application, because most of those business user had a relationship with the company before. So there were a balance of attribute variable for, for authorizations reasons that could be pulled from those application. So there is a course entire identity validation and a per attribute validation.
That is the central part of this process before concluding the process and entering just one more detail, which is in this case, the phone number, which should be validated to allow later to factor authentication in general. And then I'm getting to conclusion, what does it take to address me to be out of what I just described? Well, basically takes five things. First, the ability to address flexibly the diversity of the registration and validation flows as I just exemplify second, the possibility to manage consent capture consent course, course grain on document, fine grain on attribute, and to allow the user to withdraw and to amend what is their consent decision? Third allow second factor authentication, maybe through SMS, maybe through mobile app. Doesn't really matter. The key thing here is that second factor authentication here is relevant. Not because we don't like password. That's not the point is that in B2B, otherwise we will likely have people sharing an account, which you don't wanna have.
That's why second factor authentication is relevant here. Number four, that's where the delegation of authority kicks in. You need to have a flexible model to manage multiple layers of users with potentially at each layer, a power user to create user at that level of a level downstream, okay. With multiple types of restriction on which application and which application rights can be given at each and every level. So the conversation in number four can become fairly complex depending on the specific business need. Number five is around the rendering of everything I just described again, in B2B more way more than in B2C, there is an inclination of leveraging existing user interfaces without going API and building the UI. So of course you need to have an easy enough for, to avoid otherwise overwhelming change management processes in the adoption from the business users. That being said, and getting to conclusion, addressing B2B basically is pretty much always an architectural conversation is not really a software selection that probably the most important lesson we gain over the last couple of years.
Second, our authority delegation and registration flow are where really the variations of customer requirement, but also on vendor offering capability are peaking. So that's where if I was to give you my recommendation around where you should be giving an extra level of attention, those are probably the aspect that I would consider more relevant. Third again, we're talking B2B, of course you wanna have the ability to go API and API first is very important, but talking B2B, I would definitely would look for an API first, but maybe not an API only approach, meaning native UI and capability to optimize the time to market. And with that, Martin, I will give it back to you and
Question, thank you, Marco, what is very insightful presentation? So with that, we will directly switch to the Q a session. So if you have any questions to Marco or to me, please enter them now in the questions area and the go to webinar control panel, which you usually find at the right side of your screen. We already have a couple of questions here, and I directly wanna start with the first of these questions. So I think to what you set trust, right at the end, mark, you mentioned that a registration and validation process, or you talked about registration validation process, what you mentioned during to your targets, that this can imply an integration with CRM solution. So do you integrate Salesforce natively or others in that space? Oh,
Good question. That's the quick one. Yeah. Yeah. So, well, we do not claim to have a precan native adapter for Salesforce, although we integrated Salesforce multiple time already. Okay. So we can in, when it comes to integration, we have an API first strategy. So each and every time we do integrate with what sort of CRM very often our, we call it CRM, but it's really a custom solution is not a, is not a, is not a vendor product that we need to integrate. So we integrate, I think two, three times with Salesforce, but we never converted that into a productized adapt. OK. Not
Good. Thank you. Another question I, I see here, you said that there is always a service desk, custom care side involved. So many companies leverage solutions, such ServiceNow. Do you integrate with these?
Oh, okay. That, okay. Another integration question. Yes. Service now. Well, that's a very good question, indeed. Yeah, there is always a service desk involved, right? The bigger company. Of course, the more likely they already have some solutions such as ServiceNow to, to UN address that in a, in a, in a single way. And we do integrate with ServiceNow, meaning that by directional, we can synchronize information into ServiceNow, but we are now looking at the different level of integration with that, meaning that what we are building, and this is in the making, we want to have a native plugin for ServiceNow. So to have the ServiceNow rendering again, natively there of what you can do on people's identity. Okay. The common thing that you are required to do such as was that a password restart an activation process, change some attribute, change the consent attribute, that sort of thing will now be part of what you can enjoy. You can leverage directly from ServiceNow. Okay. Again, this is a roadmap statement. It's not yet there just to properly set expectation, but yes, it's very relevant and we do consider that extremely important.
Okay. Next one, what sort of skills and training are required for the business partners to learn how to manage other users?
Okay. Yeah. That has to do with the change management usually involved in these sort of programs. Right. Well, I have to say that. So that kind of links back to what I started, what I describe it as a scenario we usually contribute. And we are usually part of a broader program where an entire business application is being rebuilt, which is again, very much what B2B is about. Opposed back into my workforce identity days, where there was very frequently the case that you add a new component, which is an identity management piece. I'm bringing that distinction up because in B2B, yes, you have now business users capability about managing other people. And of course you need to teach them to your business user population, but at the same time, you will be also required to teach them as well. The new application, the new business application much bigger than just the identity piece that you're now introducing. What I'm saying with that is that very often that part, the change management piece due to the identity piece got, let's say is a tiny fraction of a much broader one. Okay. So to that end is not very relevant in the overall deployment of such a solution.
One more question here. When, when we look at this GDPR topic you brought up. So, so, so how frequently do you see this being already on the radar radar of your customers when you talk about B2B? So I think GDPR is pretty commonly on the radar when it comes to B2C, but is it already on the radar of, of the companies you talk with when you talk, start talking about B2B use cases?
I would say we're early days is definitely each and every time part of what we get tasked to reply in a refinery fee. That's always the case, no exception that doesn't necessarily match with that being part of phase, one of the adoption, rather of the opposite. So phase one is very much around course grain consent on terms and condition. Not really, not yet very much around a level consent.
Okay. And then, then when we look at, so you've, you've put a lot of focus on, I think this is really what, what challenge is the delegated management use cases to treasury use cases, stuff like that. How, how do you see in practice the balance of federating users? So business partner employees in versus the need for, for sort of managing them again and maybe in addition, so which types of identity providers see, do you see a trend and the identity providers towards not self managing these or relying on external identity providers? Or is it three that's usually do it in your own business partner, IDP, so to speak commonly?
No, that, that's a good question, right? Again, when it comes to business partner, you are, yeah, you have multiple needs. One of them is of course, to identify them. And that will be through Federation, but the level of trust you need to have, and the level of insurance you need to have on identity pose a slightly different challenge. So to that end, in my example, for instance, I was talking not incidentally around the validation to providing, because that, again, removes what otherwise could be a less than ideally verified identity that we are now onboarding. Okay. So in terms of trend, we see that the various flavors of AI that's in the various count are more and more relevant. So it can be, it can be of course, trans connect speed in Italy or go UK, all of them. Okay. So that's definitely more and more coming.
Okay. Even in B2B scenario. Okay. Because again, all of these people are in the citizen. Okay. And, and that's a trusted, a trusted source. So, and that's part of it. Right. But as I was expressing, in my example, there is a second dimension to that conversation, which is around what we know in terms of attributes, which are relevant for the kind of authorization we want to give to those, to those business partners. And that's where it's not just about identifying them, but it's about pulling information from other, from other sources. I wouldn't call it that as an IDP integration is more of a lookup. Okay. But it's very often the case that you have this dualism, this combination. Okay. The trusted IDP. Okay. And for end a lookup in some legacy system. So that's where we see. So Federation is fine, but it's not enough. It's not completing the picture.
Okay. So with that, we are done with the questions we have received. Thank you to all the attend for listening to this call, webinar, hope to have you soon at one of our upcoming events or webinars. Thank you, Marco, for all the insight you provided and for, I welcome for supporting this webinar and have a nice day.
Thank you very much.
