IDPro members have been hosting a Virtual MeetUp each month this year to gather as a community since we are unable to participate in person at conferences or other events. These Virtual MeetUps are a great opportunity to network with other identity professionals and learn more about IDPro’s upcoming activities.
Details of the IDPro Virtual MeetUps can be found in the #general channel in IDPro’s Slack workspace. If you need an invitation, please contact director@idpro.org.
Next IDPro Virtual MeetUp
- October 15, 2020 at 5pm PDT/8pm EDT/10am AEST (12am UTC)
Upcoming IDPro Virtual MeetUps
- November 19, 2020 at 6pm CEST/5pm BST/12 noon EDT/9am PDT (4pm UTC)
- December 17, 2020 at 5pm PDT/8pm EDT/10am AEST (12am UTC)
If you’re interested in volunteering to coordinate a global virtual meetup in your time zone, please contact events@idpro.org. In particular, assistance in Europe, Asia and Australia time zones are very welcome!
IAM MeetUps
If your local IAM MeetUps have gone virtual recently, let us know! We can help promote your event on Twitter, LinkedIn and in the IDPro Slack workspace. If you would like to share a story from your IAM MeetUp, please reach out to editorial@idpro.org and share your news with the rest of our community.
For additional details and a list of known user groups, check out the IAM User Groups page here.
Follow IDPro on Twitter and LinkedIn for more updates and join the conversation with other members in IDPro’s Slack workspace in the #general channel.
Cheers!
An Interview with George Dobbs, Board Member and Chairman of the IDPro Body of Knowledge Committee
Last month, we sat down with Heather Flanagan, Body of Knowledge Editor for IDPro. This month, as we continue our series of posts “Getting to Know IDPro,” we interviewed George Dobbs, Board Member and Chairman of the IDPro Body of Knowledge Committee. George shared his experience in the identity industry, why IDPro is so important to the ecosystem, and much more.
IDPro: Can you share a bit about yourself and how you got involved in the identity industry?
George: I took a math major in college and got an opportunity to work on computing jobs for the school administration. It was remote computing in the sense of dial-up with an acoustic modem. That led to a job with a company that sold computing time with a similar set up. Back then, companies would pay high fees to get access to storage and computing. When microprocessors became powerful enough for basic tasks, there was a demand for the skills needed to set up basic computing tasks based on such devices as the TRS-80 and eventually the first IBM PC. After a five-year stint as self-employed, I moved to an insurance company where I got involved with local area networking (LAN). Novell Netware 2.x was all the rage at that time and that was my first exposure to digital identity. As the 80’s turned into the 90’s, the bindery turned into a directory. In the 90’s the Novell packet technology and directory were overtaken with TCP/IP and Microsoft’s Active directory. I got involved then setting up gateways and firewalls. Eventually it came time to have customer and agent logins to websites. This was a new use-case that gave me the opportunity to design and build and as I moved on to another company, there was a reprise of the project. At a third company the same need came around again, but by the 2010’s the nature of the project was heavily influenced by defensive needs; financial institutions, through the internet, had become regular targets for fraud.
IDPro: What brought you to IDPro and what prompted you to join the organization?
George: I first got involved with others in the identity space with the Network Application Consortium in the late 90’s. That’s where I first heard of the Jericho project and the concept of identity as the new perimeter. I think the concept was done a disservice by the terrible name – “boundaryless computing” – that someone came up with, but the idea was prescient. Boundaries and zones remain part of the toolkit but identity has become a key aspect of security. So when I heard Ian and Sarah call those at the Cloud Identity Summit to action, I figured the need for protection from fraud and other attacks is a good reason for collective action, so I joined IDPro.
IDPro: Can you explain your role in IDPro?
George: I’ve been a board member since the first board was seated. It seemed clear that the most important thing to take on was the Body of Knowledge so I helped by framing how that would work in our organization and forming a committee of which I have been the only chair to date. We drafted a “table of contents” and defined a process to find and select the Principal Editor which was accomplished about 18 months ago when we found Heather. Heather has met and exceeded our expectations, so my role has changed from first mover to something more akin to guide or coach.
IDPro: Why do you think IDPro is important for the identity industry and ecosystem?
George: My first response is that the very notion of an identity industry is only now being incorporated into mainstream thinking. In the past, if it was thought of at all, it was as part of the “information security” domain. There have been many attempts to improve the identity landscape over the years but what IDPro attempts to provide is a big tent into which all sorts of topics and roles relating to the identity industry can fit and be knit together. Hopefully this allows players from government, industry, education and even concerned citizens, to provide foundational knowledge for the next generation and – perhaps more importantly – provide guidance to society as a whole as we move more fully into the inevitably digital future.
Identiverse Virtual has been a great experience so far, with sessions from IDPro members such as “The Skills and Experiences of Identity Practitioners,” “Modern Identity for Developers 101,” “Mission: Impossible – Identity Mythos,” and more. Even though the event has been a lot of fun, we do miss our in-person gatherings to network with fellow identity practitioners.
So, we are excited to host our annual public plenary meeting this week, on Wednesday, July 29 at 12 PM MDT (2 PM ET). The plenary meeting is open to all Identiverse attendees and there will be a live Q&A during the broadcast. We hope you will join us to learn more about IDPro, our progress so far, and what we anticipate for the future. Register for the public plenary here.
Following the meeting, we are sponsoring an Identiverse Happy Hour via Zoom from 8 PM to 9:30 PM EDT (5:00 PM PT, 8 AM JST, 10 AM AEST). This event is open to ALL Identiverse attendees, so please join us to discuss your virtual conference experience, share your opinions on presentations, play some games, and maybe enjoy a cocktail or two. Details can be found via email or in IDPro’s Slack workspace. If you need an invite, please contact membership@idpro.org.
Don’t miss IDPro member presentations at Identiverse 2020! View the upcoming presentations here. Also, all previous presentations are available on-demand.
Follow IDPro and Identiverse on Twitter for more updates and join the conversation with other members in IDPro’s Slack workspace in the #Identiverse channel or network with other identity professions in Identiverse’s Slack workspace.
Cheers!
We recently sat down with Heather Flanagan, the person responsible for editing and managing the development of IDPro’s Body of Knowledge. With the latest Issue now available to the public, Heather had a lot to share about her experience within the identity industry and her work on this important contribution to the community.
IDPro: Can you share a bit about yourself and how you got involved in the identity industry?
Heather: How does anyone get involved in the identity industry? By accident! My education is actually in Medieval English History and Library Science, and yet somehow, within six months of graduating, I was managing a Galacticom Bulletin Board System (BBS) and picking up books on DNS and Sendmail. Once an individual starts administering IT systems, managing identity and access is a fundamental part of the job. It only grows from there.
It’s been 25 years since that BBS and 15 years since IAM was first formally recognized as part of my job. It’s been about 10 years since I went independent and IAM (in particular academic federated identity), and standards development became the majority of what I do.
IDPro: What brought you to IDPro and encouraged your decision to join?
Heather: I think I was one of the first 100 people to join IDPro – back when it was incubating in Kantara – and I was on the committee of two that developed the initial Code of Ethics. One the organization began forming, joining was never in question. By that time, I had already observed that getting a handle on the ins-and-outs of IAM took a minimum of two years for everyone. Having a professional organization on hand to serve as a place to consolidate discussion, support, and group therapy made for an easy decision: “wait, we as an industry aren’t doing this already? Let’s get this party started!”
IDPro: Can you explain your role in IDPro and how it has evolved?
Heather: Once IDPro was really off the ground, I continued to read the newsletter but most of my time was focused on being the RFC Series Editor, providing executive oversight for the publication of RFCs for the IETF, IRTF, IAB, and Independent Submissions stream. So I found out about the IDPro Principal Editor role almost too late, but how could I not apply? This is like a dream role: I get to design the publication process from the ground up, rather than inheriting a rather calcified process designed by someone else 30 years ago. I get to offer back to my core community of IAM practitioners the kind of thing I’m really good at: words, process development, and IAM.
That’s actually a point I’d like to press on for just a moment: efforts like the IDPro Body of Knowledge, or really any project at all, need so much more than just the visionaries and architects. It requires newbies to point out where information isn’t clear enough to educate someone new to the field. It requires people whose specialty might be writing and not architecture. It requires people who do more with implementation than design. Every single person reading this has something that the IDPro BoK needs to really be successful, whether they believe that or not.
Fast forward to today, and I’ve found the role needs even more of the skills I have in my portfolio. It needs more volunteer wrangling, social media outreach, and the development of proposals for new lines of effort (in this case, profiles and the certification program). So, what was a dream role for me got even better! I have a brilliant opportunity to help the IAM community far beyond my usual home of academia and standards, and that’s a fantastic feeling.
IDPro: Why do you think IDPro is important for the identity industry? How does the Body of Knowledge fit into this?
Heather: The IAM industry is still too dependent on on-the-job training and mentorship models. I participated in a webinar earlier this month called “Hiring for Identity and Access Management,” with a higher-education focused organization, InCommon. The point of the webinar was that hiring experienced IAM practitioners is extremely difficult. I think that is the case in every sector, not just higher education. The IDPro survey has highlighted just how few people feel proficient in their roles until they’ve been in their jobs for years.
How are we supposed to improve as an industry, an industry that is so important because IAM touches every aspect of the digital experience, if we can’t get practitioners to feel proficient until they’ve been doing this for years? There has to be a better way, and I’m hopeful that the IDPro Body of Knowledge and the future certification program can be that better way. I want to see us establish a common baseline that will allow organizations to really focus on what’s unique to their situation, and cut out teaching people what IAM means.
No one knows IAM better than the people in the field today. I want those people to take their knowledge and their passion for what they do and help me turn the Body of Knowledge into something we as an industry can be proud of.
On the IDPro website you can access the full Body of Knowledge, learn about membership, and better understand how the organization is supporting the identity industry.
Don’t miss IDPro member presentations!
Due to travel restrictions and in the best interests of attendees, Identiverse 2020 is being held virtually as a series of webinars timed to accommodate a global audience. All previous presentations are available on-demand (watch sessions from the previous two weeks here).
View the full Identiverse agenda here and register to attend. Join the conversation with other IDPro members in IDPro’s Slack workspace in the #Identiverse channel. Also, Identiverse has a separate Slack workspace for support help, to discuss hot topics, and network with digital identity professionals. If you need an invite, or if you’re not receiving the email list messages, contact membership@idpro.org.
Follow IDPro and Identiverse on Twitter for updates. Don’t miss this year’s Identiverse presentations!
Following are IDPro members presentations for the remainder of the Identiverse 2020 virtual event:
Week 3: June 29 – July 3
Monday, June 29, 10:30 – 10:55: A Crew as Nuts as You Are: Building a Local IAM User Group
The ability for identity practitioners to network with their peers at a local/regional level on a periodic basis is incredibly valuable, especially for those who do not have the means to travel to other events where such professionals gather. These groups provide a forum for sharing technical presentations and real-world experiences that help not only the practitioner, but their employer as well. Ocean’s Eleven, meanwhile, is the classic heist movie where a small group of people with a plan — and a killer soundtrack — craft something extraordinary. Steve “Hutch” Hutchinson and Mike Kiser have both started IAM user groups in their city and, with a little help from Clooney & Pitt, will provide you with a blueprint for something no less ambitious than ripping off three casinos: starting your own identity focused meetup. So join us and we’ll show you how to pull off the meeting, plus maybe even a Boesky, a Jim Brown, a Miss Daisy, two Jethros and a Leon Spinks, not to mention the biggest Ella Fitzgerald, ever. – Speaker/s: Stephen Hutchinson, Mike Kiser
Monday, June 29, 12:00 – 12:25: Distributed Open Identity: Self-Sovereign OpenID: a Status Report
Self-sovereign Identity is a philosophy. Distributed Identifier (DID) and Verifiable Credentials are aspirational implementations of it. However, a completely new protocol may face formidable adoption challenges as it will easily get into a chicken-and-egg situation of user adoption and service adoption. From this point of view, minimizing the wire-protocol differences to the current mainstream protocols have large advantages as it would be easier at least to persuade service providers to adopt it. After all, most users use its online identity to get services from those service providers and not for the sake of using the identity. In November 2019, OpenID Connect WG decided to separate out Chapter 7 of OpenID Connect Core to make it an independent specification to close the gap between “Self-issued OpenID Provider” and “Self-sovereign Identity”. This session will provide an overview of the development since then and brings the audience up-to-speed on what is happening in the space including Demo of such implementations. It is a follow up of the Identiverse 2019 session “SSO: Self-sovereign OpenID Connect – a ToDo list”. – Speaker/s: Preeti Rastogi, Nat Sakimura
Tuesday, June 30, 10:30 – 10:55: Mission: Impossible – Identity Mythos
If there’s one thing that we can rely on the Mission: Impossible movies to deliver, besides awesome shots of Tom Cruise running like only Tom Cruise can, it’s the use of technology as a core part of the Impossible Mission Force’s plan. These plans often involve bypassing security systems or fooling opsec in a way that plays with identity. Your mission, should you choose to accept it, is to join me as I show how the M:I series has some pretty interesting lessons on how to do identity-based security right (or wrong). There are misconceptions about identity technologies that many security and even identity professionals have today, that the (non IDPro) writers of the series have figured out, and have used to great effect in creating the thrills of the M:I movies. Looking past the action, there are same great lessons we can all take away that can make our security programs better, help our organizations avoid some common (and costly) mistakes, and keep any potential Ethan Hunt’s out of your business. And unlike those coded messages, these lessons won’t self-destruct in 5 seconds. – Speaker/s: Nishant Kaushik
Tuesday, June 30, 11:00 – 11:25: SailPoint Presents: LogMeIn’s Identity Governance Vision Uses the Power of AI & Machine Learning
Supporting and securing remote workers has never been more critical than now, and identity needs to be the lynchpin of that strategy. Companies are facing significant changes in their programs as AI and machine learning technologies redefine how businesses do identity. The future of identity is here. Now, organizations of all sizes are starting to use AI & Machine Learning (ML) to build identity programs efficiently. Kayla Williams, Director of GRC at LogMeIn (makers of LastPass) and Po Wang, Sr. Manager, CIO Portfolio Manager, will share their identity journey on how AI/ML technologies are integral to their strategy, how the integration of systems and process changes was significant in their process, and the efficiencies they’ll gain with a cloud-first identity program. – Speaker/s: Po Wang, Kayla Williams
Wednesday, July 01, 10:00 – 10:50: Identity Standards: What’s Up, What’s New, What’s Next
Alex will share his thoughts on the importance of Open Standards, and some areas of amazing recent progress. Additionally he will discuss a few emerging areas and the opportunity they present for enhancing user security and providing breakthrough personal privacy. – Speaker/s: Alex Simons
Wednesday, July 01, 11:00 – 11:25: Microsoft Presents: A Zero Trust Approach for Today’s World
Organizations have traditionally invested in network as a perimeter. In current times with the shift to remote workforce, organizations had to quickly adapt to the new reality and enable secure access to corporate resources. End users are working from home and VPN isn’t always a viable option. A Zero Trust approach to securing your data is more important than ever. In this session, we will demystify Zero Trust and dive into steps to start your zero trust journey. – Speaker/s: Nitika Gupta
Wednesday, July 01, 12:00 – 12:50: Scaling Strong Authentication
Join our expert panel for an in-depth discussion of the challenges and pitfalls of handling strong authentication at large scale – and an exploration of possible solutions. – Speaker/s: Lorrayne Auld, John Fontana, Blake Hall
Thursday, July 02, 12:00 – 12:50: A Balancing Act: Identity, Privacy, and Security in a Data Sharing Economy
As the value of enterprise data increases, so too do the risks to the enterprise, to the individual, and to the industry. Do you as an identity, privacy, or security professional know how to recognize those risks, let alone mitigate them? If we do this right, everyone recognizes meaningful value. If we do this wrong, everyone loses. As professionals in these areas, you need to consider information governance, regulatory compliance constraints, and data provenance. Join this panel of experts as they discuss recognizing and overcoming the risks, maximizing data use and sharing opportunities, as well as impart practical techniques for implementation. – Speaker/s: Pamela Dingle, Heidi Wachs, Alice Wang
Week 4: July 6 – 10
Tuesday, July 07, 11:00 – 11:25: Ping Identity Presents: Passwordless: Transform Customer Experiences in the New Digital Era
By 2022 Gartner expects that 60% of large and global enterprises, and 90% of midsize enterprises, will deploy passwordless verification. With most businesses delivering friction-free sign-on to their customers that doesn’t require passwords, you will have to keep up to stay competitive and retain market share. No matter where you are on your journey to get rid of passwords there are important considerations you have to make. What is the most secure password substitute? Should I allow passwordless access for all apps? Which authentication factors will my customers actually use? How many passwordless authentication factors do I need to offer? In this session, we’ll tackle these questions and more in order to help you navigate the critical decisions you’ll need to make as you embark on your passwordless journey. – Speaker/s: Rob Otto
Tuesday, July 07, 12:00 – 12:25: Enabling Scalable Multi-Lateral Federations with OpenID Connect
Numerous large-scale multi-lateral identity federations are in production use today, primarily in the Research and Education sector. These include national federations, such as SUNET in Sweden, regional federations such as NORDUnet in the Nordic countries, international federations with thousands of sites, such as InCommon, and even inter-federations among dozens of federations, such as eduGAIN. Yet these existing federations are based on SAML 2 and require the federation operator to poll the participants for their metadata, concatenating it into a huge file that is distributed to all federation participants nightly – a brittle process with significant scalability problems. Responding to demand from the Research and Education community to migrate from SAML 2 to the simpler OpenID Connect protocol, the OpenID Connect working group has created the OpenID Connect Federation specification to enable this. The new approach incorporates lessons learned from existing SAML 2 federations – especially using a new, scalable approach to federation metadata, in which organizations host their own signed metadata and federation operators in turn sign statements about the organizations that are participants in the federation. As Shibboleth author Scott Cantor publicly said at a federation conference, “Given all my experience, if I were to redo the metadata handling today, I would do it along the lines in the OpenID Connect Federation specification”. This presentation will describe progress implementing and deploying OpenID Connect Federation, upcoming interop events and results, and next steps to complete the specification and foster production deployments. The resulting feedback from Identiverse participants on the approach will be highly valuable. – Speaker/s: Michael Jones
Wednesday, July 08, 11:00 – 11:25: Auth0 Presents: A Centralized Identity Strategy Using Standards Helps Minimize Threats
Modern architectures continue to become more distributed and fractured. How can developers continue to develop and build what they understand without having to become identity experts? How can they do that and ensure that their applications remain secure? A centralized, standards based identity management system can provide a system that is easy to interact with without requiring expertise or a reduced security footprint. – Speaker/s: Carlos Mostek
Thursday, July 09, 10:30 – 10:55: Ethics in Data Privacy: Is User-Owned Data the Future of Data Privacy?
As the movement towards data privacy grows, there are a number of concepts for how users can regain control over their data – data ‘dividends’, person blockchains, cash-for-data exchanges, but all have both upsides and downsides. This session explores a few different schools of thought around the pros and cons of user-owned data and alternatives for the future of ethical data privacy. – Speaker/s: Marla Hay
Thursday, July 09, 12:00 – 12:50: Dev, Sec, or Ops: The Future is Hybrid and Automated
Many enterprise practitioners are struggling to adopt infrastructure-as-code, let alone containers, and automated pipelines. Not all of the challenges are technical, and many are rooted in leadership not being comfortable with the culture change that comes with automating processes and trusting code over people. Our panel will talk about some of the real-world struggles their organizations have faced moving to a DevOps culture both from a technical and cultural perspective. The panel’s viewpoints will cut across both industries (healthcare, financial services, government) and business relationships (vendor, integrator, and customer) to show different perspectives on how the problems are being solved. – Speaker/s: Matt Topper
Friday, July 10, 10:00 – 10:50: Demo 2020 of the Kantara Personal Data Consent Receipt!
You will hear lots of talk about the Business-Legal-Technical sandwich** at identity and security conferences. Come hear about what a BLT looks like with real companies and regulators working out how the Kantara Consent Receipt can work in the real world for consumer data protection. Our presenters will share their insights about how the BLT works, concerns and hurdles, and what improvements are still needed. It’s been a busy year since Kantara members demonstrated 6 real implementations of Consent Receipts at Identiverse 2019. And the pace has just kept increasing! In this Masterclass/Demo session we’ll dig into: •the consent receipt specification and, how you can use our new data receipt framework to build your own personal data receipt customized to your scenario, •how our member companies have implemented receipts in innovative ways, •how our partners at FDX have made it part of their Open Banking API work, •the conversion of the Kantara specification into an ISO International Standard, and •what a state consumer protection regulator is doing to give their constituents data protection tools. If you’ve ever wondered why people are not given a receipt when asked to give up their data, this is the session for you! ** No actual sandwiches were harmed during the preparation of this session – but they certainly were delicious. – Speaker/s: Andrew Hughes
Week 5: July 13 – 17
Monday, July 13, 10:30 – 10:55: Beyond 2.0: OAuth, TXAuth, XYZ, and Growing New Standards
The OAuth 2.0 protocol has been wildly successful across the internet, but it has many shortcomings that come to light in today’s world. We’ve learned a lot about what works and what doesn’t in practice, and the time has come to build on those lessons. Come learn how we are building the next generation identity and security protocols that could lay the groundwork for the next decade of internet security. – Speaker/s: Justin Richer
Tuesday, July 14, 10:00 – 10:50: Next-Gen Authorization Throwdown: It’s Not Your Grandfather’s OAuth
OAuth has seen several iterations over the last decade as the expert community has worked to solve difficult security, authorization, delegation, and consent challenges on behalf of both enterprises and end-users. We’re now in “interesting times” as OAuth 2.0 is being stretched – some might argue to a breaking point – to cover new use cases. How should we enable fine-grained authorization? How similar should our handling of consent and authorization be? Can enterprise authorization and cross-domain authorization use the same model efficiently? Where do authentication inputs end and authorization decisions begin? And what about Alice? Join our panel of experts to hear their differing perspectives on OAuth innovation and how its next wave(s) of iteration must proceed for success. – Speaker/s: Daniel Fett, George Fletcher, Eve Maler, Justin Richer
Tuesday, July 14, 11:00 – 11:25: Radiant Logic Presents: Battling Repetition & Inefficiency: How Colorado Consolidated Identities
The State of Colorado Office of IT works to empower the state with flexible technology that will drive sustainable and intelligent business decisions. However, with 17 different state agencies acting as independent IT shops, there was a lot of product repetition, process inefficiency, and difficulties in collaboration across agencies. Working together required extensive firewall and infrastructure maneuvering. In 2008, the Governor issued a mandate requiring a consolidation of the state’s agencies into one overarching IT department. One of the goals for the newly created agency was creating a unified directory from all of the independent directories. This session will talk about how a federated identity and directory service was used to meet this requirement. As a result of doing this, all of the CO state agencies are able to collaborate cohesively together as one, which in turn decreased redundant tasks, increased productivity, strengthened overall security and created efficiencies all around so that now synergies are actually realized. –
Tuesday, July 14, 12:00 – 12:25: Identity Kill Chain: A Hacker’s Eye View of How your Systems Get Pwned
A kill chain is the set of steps an attacker takes to achieve their objective. Come walk the Identity kill-chain from an attacker’s perspective: What does an attacker see as they are taking over your domain? What are the tools, and how do attackers apply them, and how do they move from one guessed password to total domain take-over? In this nerve-wracking session, through live demos of current attack methods you’ll gain a deeper understanding of the criminals’ “tools of the trade,” where the weakest links in identity systems are, and how best to break the kill-chain for each step, walking away with a deeper understanding of attack mechanics and a greater confidence in your ability to defend your organization. – Speaker/s: Alexander Weinert
Wednesday, July 15, 10:00 – 10:50: Keynote Panel: Identity at Scale
The ways and frequency with which we use our identity data are increasing at an almost unimaginable rate. Dealing with Identity at scale is a challenge we will have to face. In this panel, hear how some of the largest providers and users of identity services are addressing those challenges today, and discover approaches and techniques that you will be able to use in the future. – Speaker/s: Richard Bird, Sue Bohn, Sam Srinivas
Wednesday, July 15, 12:30 – 12:55: Vectors of Identity: A Model for Better User Experience
In many identity flows today, the user experience is the same regardless of the operation the user is trying to perform. This often means that from the user’s perspective, they have a binary experience; either they are already logged in and are NOT challenged, or they are not logged in and are challenged. These concepts go beyond “adaptive authentication” in that “authentication strength” is only one of the vectors being considered. This talk will define a set of identity “vectors” that can be used to provide better user experiences across the full life-cycle of user identity and service interactions. – Speaker/s: George Fletcher
Thursday, July 16, 10:30 – 10:55: The Password Mess: Your Security Policies Are Destroying Your Users
We all use passwords to secure things, and rarely do people actually like them from either a security or usability perspective. This is especially true with the arcane composition and rotation rules that we all face. But do these rules help our security, and are we even using passwords correctly to begin with? In this fast-paced talk, NIST Digital Identity Guidelines co-author Justin Richer will walk through how we got into this password mess and what we can do it about it. – Speaker/s: Justin Richer
Friday, July 17, 10:00 – 10:50: Modern Identity for Developers 101
Modern identity promises to solve some of the thorniest problems that historically plagued handling authentication and access control in applications. That sounds great in theory, but how do thinks really look like when the rubber hits the road – what does it take to incorporate modern identity in your applications development practice? Come to this session to learn the basis of modern identity development and be better equipped to understand and participate to more advanced developer themed sessions, at Identiverse and beyond. – Speaker/s: Vittorio Bertocci
Friday, July 17, 10:00 – 10:50: The Burden of Proof
While the vast majority of deployments utilize bearer tokens, OAuth does have a rich and troubled history with proof-of-possession (PoP) tokens. The popular canon is that PoP was the reason OAuth 1.0 failed and WRAP abandoned it entirely. The original editor of the OAuth 2.0 spec publicly rage quit over lack of PoP support. Various subsequent standards efforts to add proof-of-possession to 2.0 by extension have stalled out (PoP Key Distribution + Signing HTTP Requests) or been effectively killed off by an unnamed huge search company that also makes a browser (Token Binding). A few efforts have seen more success and made it to RFC but are only partial solutions (PoP Key Semantics for JWTs) or are somewhat niche (MTLS). Recent efforts at rebooting the work (DPoP) garnered excitement among some but have also been met with resistance in the standards development community. It turns out that it’s hard. This session, part history class, part existential crisis, part technical examination, part workation photo slideshow, and part personal tragedy, will explore proof-of-possession in OAuth and endeavor to equip you with the knowledge to discern fact from fiction when it comes to cryptographic defenses against the use of stolen OAuth tokens. – Speaker/s: Brian Campbell
Week 6: July 20 – 24
Monday, July 20, 10:30 – 10:55: Transaction Tokens: Solving the External/Internal Authorization Problem
Any system that deals with “external” clients invoking services has to deal with extending the authorization model of the system to the external clients. The internal authorization model (roles, attributes) often does not translate well to authorization mechanisms used by the external clients (e.g. OAuth2 scopes). For example, an OAuth2 scope may not match well with an internal role as the mapping might be 1:n or even n:n. This talk will explore a mechanism that allows for the external authorization model to remain simple for developers while providing a multi-level (coarse-grained to fine-grained) authorization model internally. – Speaker/s: George Fletcher
Monday, July 20, 12:30 – 12:55: America’s Next Role Model: Revolutionary Role and Access Modeling Powered by AI
Managing and provisioning access can be quite a daunting task in mid or large sized organizations. Having a good answer for “Who should have access to what?” is not easy. With a myriad of existing applications, accounts, file systems, etc. experiencing growth with an ever-changing workforce, awarding and maintaining the right access to the right identity can be quite an ordeal. An accurate model of the access structure makes all the difference when it comes to compliance. Identity governance is predicated on the principle that strongly similar identities should be awarded similar access. Identities, their attributes, and associated access patterns can then be analyzed and modeled by a powerful and highly flexible graph data structure where we can easily track, map, and manage the dynamic relationships between these entities as they evolve. Roles can be thought of as insightful labels which summarize clusters of strongly similar access patterns. In this talk, we will give an overview of a novel network-graph approach to role mining and access modeling. This new approach enables automation, scalability, and optimization of resources while providing a complete solution to managing access across the enterprise. – Speaker/s: Mo Badawy, Jostine Ho
Tuesday, July 21, 10:00 – 10:25: User and Thing Identity in the “Zero Trust” Networking Era
Here we are in 2020 and MAC address is still the prominent identifier used for network identity and policy derivation for the millions (likely billions) of “things”, those IoT and consumer devices connected to enterprise networks. Yes, MAC address. That network interface “hardware” identifier that can be changed in software and is often randomized on user-centric devices in an effort to preserve user privacy. The “Zero Trust” model has brought increased attention to transport-agnostic continuous authorization for applications and resources but network identity and policy-based segmentation still play a critical role at the network edge. We’ll look at new technologies and protocols like the Device Provisioning Protocol (DPP) which simplifies provisioning for end-users and enterprise administrators as well as provides a persistent, cryptographically backed device identity to the network. We’ll also look at some older technologies, like Tunneled EAP (TEAP), that have resurfaced to solve new use cases like binding a user and machine identity together on user-centric devices like laptops, tablets and smartphones. – Speaker/s: Tim Cappalli
Tuesday, July 21, 11:00 – 11:25: Auth0 Presents: Credential Stuffing Attacks: What Are They and How to Combat Them
As a central authentication service that processes billions of logins a month, credential stuffing attacks are the most common threat Auth0 observes. On some days, these attacks originate from more than 50,000 IP addresses and may account for as much as half of all login attempts using our platform. These attacks can lead to fraud, loss of reputation, and ultimately, loss of revenue. Learn how credential stuffing attacks work, what effect they can have on your company, and how you can fight back. – Speaker/s: Andrew Akers
Tuesday, July 21, 12:00 – 12:50: The Skills and Experiences of Identity Practitioners
Knowing what skills you need to become an identity practitioner isn’t obvious. Picking which technical and nontechnical skills you need to strengthen isn’t a straightforward choice. To get clarity you need to hear from other people who’ve been in the same place in their careers. In this panel co-hosted by IDPro and Women in Identity, you will:See the results from the 2019 IDPro Skills and Program Survey revealing the skills that digital identity practitioners rely on for their successHear from professionals from Amazon, Microsoft, Salesforce, and Thomson Reuters on their journey towards becoming a successful identity practitionerKnow what skills you should strengthen and which you can leave alone Learn by asking a panel of practitioners in different stages of their careers for candid insights as to how to become a stronger identity practitioner. – Speaker/s: Pamela Dingle, Ian Glazer
Wednesday, July 22, 10:00 – 10:50: The Consumer Identity Panel
Dealing with identity – authoritative, verified, or just plain account-oriented – at consumer/citizen scale is not easy. Delivering an improved user experience at scale, while still ensuring appropriate security and privacy safeguards, is a major challenge. Our panel of experts shares their experiences, and discusses their aspirations for the future. – Speaker/s: Jeremy Grant, Charles Walton
Wednesday, July 22, 12:30 – 12:55: Are You really You? Identity Proofing with NIST SP 800-63-3
The global emphasis towards identity-centric protection is crucial towards combatting the increasing number of data breaches by unscrupulous individuals. In the worst cases, a hijacked identity belongs to a privileged user, allowing the imposter to gain access to key systems or to create synthetic identities to obtain all types of services or assets. They use what is considered “private” information as the basis for establishing a fraudulent digital identity. It is essential to establish strong identity proofing processes to help combat these fraudulent online identities as well as to establish trust in a digital identity. The government is taking a serious look at improving their identity proofing processes. The newly released OMB M-19-17 specifically discusses how federal employees and contractors are required to be identity proofed and credentialed following NIST SP 800-63-3 digital identity guidelines. This session will explore the processes necessary for organizations to meet the remote identity proofing requirements for Identity Assurance Level (IAL) 2 and IAL3 following NIST SP 800-63-3 guidelines. It will also tackle the challenges most organizations face meeting these requirements. Finally, the session will provide a worked example to help organizations document their identity proofing processes and requirements as prescribed by the NIST standard. – Speaker/s: Lorrayne Auld
Friday, July 24, 10:00 – 10:50: Microsoft Masterclass: Manage and Secure All Your Apps with Identity as the Control Plane
Today, secure application access is a key challenge organizations face when implementing a Zero Trust strategy. Applications can live anywhere – in the cloud, on-premises, as a service, or on a mobile device – and are used from anywhere, at any time by employees and business partners. In this masterclass, we will discuss how identity can be the control plane to manage and secure all applications – from Office 365, popular SaaS apps and traditional on-premises applications to custom-built lines of business applications. Key learnings: -Learn of the core benefits of bringing all applications under one integrated identity platform -Learn about the different integration pathways available to bring all your applications under one IDP -Some of the common best practices to follow and pitfalls to avoid when trying to migrate applications to a single IDP -Learn about new integration capabilities with your existing infrastructure. – Speaker/s: Jeevan Bisht, Jairo Cadena
Week 7: July 27 – 31
Monday, July 27, 12:00 – 12:25: Ping Identity Presents: Best Practices of Identity in an Era of Ever-Shifting Boundaries
In these uncertain times of increased work from home and heightened business demands, your IT organization likely found itself in a sudden stress test of the scale and maturity of your employee identity and access control systems. As you tackle immediate and long-term improvements, you may find it beneficial to compare your checklist against others through the lens of a blueprint for workforce identity security best practices, including initiatives like passwordless authentication, API security, and Zero Trust. This session equips you with clear, best practices for enterprise workforce Identity and Access Controls—plus, a framework for calculating and building a business case in terms of increased productivity, agility, and security, for your evolving workforce needs. – Speaker/s: Baber Amin
Monday, July 27, 12:30 – 12:55: So You Want to Base on Consent?
Many people seem to believe that having their customers pressing “Agree” button is good enough to collect their “consent”. That’s actually not the case. Obtaining privacy consent has very high bar partly because that is the exception mechanism that you can resort to only when other lawful bases for the processing of personal data does not work. This session will briefly touch on other lawful bases and what is needed for potentially valid consent, then goes on to explain the requirements for privacy notice and consent process set out in “ISO/IEC 29184 Online privacy notices and consent”. ISO/IEC 29184 is an international standard that has been in making for the last 5 years. Stakeholders involved in the discussion included data protection authorities around the globe, technical community, lawyers, and businesses. It sets out the requirements for 1) What are needed to be in a privacy notice, 2) What are needed to be done in obtaining the consent, 3) What are needed to be done in the maintenance of privacy notices. For any business that wants to respect customer privacy, this document provides excellent guidance on what needs to be followed. – Speaker/s: Nat Sakimura
Tuesday, July 28, 11:00 – 11:25: Microsoft Presents: Identity Governance for All your Users Made Easier Through Analytics
The growing number of users, devices, and apps connected to your network has made it increasingly difficult and time-consuming for organizations to proactively detect and remediate access risk. Historically, identity governance solutions assumed that the organization knew exactly what resources to protect and that they are proactively applying the required controls, which could result in insufficient coverage, particularly for cloud apps. In this session we will cover how analytics and machine learning can be used to automate the governance lifecycle management for both internal and external user access and ensure that users only have the access they need. Come learn how analytics can help you: •drive user productivity through automatically granting access to SaaS applications based on usage patterns •drive better recommendations and automation for reviewers who periodically review access •programmatically remove users who are no longer required. – Speaker/s: Rahul Prakash
Tuesday, July 28, 12:00 – 12:25: Will User Experience Kill Open Banking?
Within five years, Open Banking will be the norm rather than the exception in financial markets worldwide. But for all of the hype, there are some serious issues limiting its promise of data portability with informed consent. While the identity security specifications are generally well designed in each jurisdiction, user experience (authentication, user consent and ongoing authorization) is not as easy or as seamless as it should be. What can we learn from Open Banking experiences in the most mature geographies — the UK, Australia, New Zealand and Europe? How has each jurisdiction designed its user experience? How has this, in turn, impacted user take-up? How have open standards been used (or modified) to fit local Open Banking requirements? How has that made the identity experience more transparent, seamless, or easy — for end users, developers and implementers — or not? This session will detail the important lessons from a user experience perspective, cover the efforts being made to remediate existing problems, and make recommendations for Open Banking’s implementation in emerging markets, like the USA. – Speaker/s: Mark Perry
Wednesday, July 29, 10:00 – 10:50: Better Identity at Two Years: Progress, Problems & Promise
Two years ago, the Better Identity Coalition brought together leading firms from different sectors to publish “Better Identity in America: A Blueprint for Policymakers.” At the time, the United States was still grappling with the aftermath of the Equifax breach and questions that breach raised about the viability of certain aspects of the country’s identity infrastructure. The Blueprint laid out a set of five core recommendations for how the government should help, along with an action plan for Congress, the Executive Branch, and states. Two year later, the Blueprint has gotten good reception from Democrats and Republicans alike. The White House has embraced some of its core policies and Congress is considering legislation that would put many others into law. This panel will discuss where we’ve made progress in digital identity and where we still have problems – and discuss what might happen next in the year ahead. – Speaker/s: Jeremy Grant, Matt Thompson
Thursday, July 30, 12:00 – 12:50: Open Banking APIs Convergence: A Holy Grail or A Reality?
Open Banking is becoming the front line of the data economy in our era. It is seen as a field that fosters new industry that many governments are requiring the implementation of secure but usable APIs as part of their economic growth policy packages. At the same time, it also is closely related to the data protection and privacy policy point of view: it is the forefront in both user consent management and data portability. Given the situation, different geography has been pushing the envelope in their own ways. However, there also seems to be some desire to converge as creating local standards that are not interoperable would lead to higher long-run costs and is likely to cause more security risks. This panel discusses the recent developments, similarity and differences among open banking APIs from different geography including UK, Germany, France, Australia, India, and Japan. It will also touch on the importance of the common test harness on the interoperability as well as on the potential impact of cross-border eKYC. – Speaker/s: Nat Sakimura
Week 8: August 3 – 7
Tuesday, August 04, 10:00 – 10:25: Making Identity a Viable Perimeter in the Cloud
Papers and presentations routinely reach the conclusion that “Identity is the new Perimeter,” and then call it done. The real work when making identity a viable perimeter for cloud and hybrid applications takes a bit more effort! This session draws on three real-world customer scenarios to demonstrate how to successfully navigate this challenging transition. We’ll see how these cloud deployments leverage standards and technologies – including SAML, OAuth, MFA, PIM/PAM, and strong encryption. Together, these ensure a level of security that meets institutional requirements and equips you with techniques to help convince your security peers that modern identity controls provide the perimeter the cloud demands. – Speaker/s: Jonathan Sander
Tuesday, August 04, 10:30 – 10:55: App2App: Improving the Third-party Authorization User Experience on Mobile
Mobile devices are key parts of our daily lives; how can identity architects leverage existing standards to ensure a smooth mobile-first authentication/authorization flow for third party mobile apps? The first party mobile experience for authentication has come a long way in the last 10 years. The majority of modern mobile devices now have built in secure key stores with biometric protection, and these are used to great effect to create secure native mobile applications with slick authentication. Joseph describes how we can extend this experience to third party native and web apps using standard OAuth2 or OpenID Connect protocols, with a quick journey starting with an example of the user experience we’re aiming for. We show the architecture of a system and the snippets of code third party mobile developers need. We also look at some of the common pitfalls, the pro & cons of alternative mechanisms like CIBA, security implications, anti-patterns and other lessons learned from deploying app2app across the UK OpenBanking ecosystem, along with the wider question of “Does my authorization server need a companion mobile app?”. – Speaker/s: Joseph Heenan
Tuesday, August 04, 11:00 – 11:25: AWS Presents: Intelligent Access Administration
Ensuring that the access permissions associated to cloud resources only provide access as intended is an important enterprise use case. As enterprises scale, managing least privilege can become increasingly challenging. This session dives into how automated reasoning can apply logic and mathematical inference to assist administrators with managing access at scale. – Speaker/s: Andrew Gacek, Ujjwal Pugalia
Wednesday, August 05, 12:00 – 12:50: Microsoft Masterclass: Upgrade your Apps Authentication from AD FS to Azure AD
Microsoft Active Directory Federation Services (AD FS) has proven to help organizations start their digital transformation journey by improving access to their cloud and web apps. However, the rapid evolution of the security landscape calls for a more modern and more scalable solution to increase app security, improve employee productivity, and reduce IT costs. Join this masterclass to learn how you can use Azure Active Directory (AD) as your central identity platform and upgrade from AD FS to secure all your apps directly from the cloud and reduce your dependency on on-premises identity systems. During the session, we’ll walk you through the available Azure AD tools and features to help you discover and reconfigure your AD FS apps as well as some best practices to ensure a smooth migration for all your users. Although, we will be focusing on ADFS, the concept and best practice can be applied to migrations from other IdPs. – Speaker/s: Ramiro Calderon, Luis Leon
In our article “Dating, Drones and Digital Identity,” we explored the need for identity verification within internet dating sites and shared some examples of what the process could look like. Well, a lot has changed since then.
Last year, a Stanford sociologist, Michael Rosenfeld, published a report which found that many couples are more likely to meet online than through personal connections, creating a $6 billion global industry. And since the implementation of social distancing measures in the U.S., there has been an increase in online dating app usage. According to Fast Company, Bumble has reported an overall 21% message increase, with substantially more increases where COVID-19 has been most prevalent.
With cities such as San Francisco and New York seeing an increase in messages of 26% and 23% respectively and individuals still interested in meeting face to face, online dating platforms have needed to shift their focus to keep their companies running. For example, Coffee Meets Bagel and Match is pushing video-based features, making it simpler for their users to participate in virtual dates.
Online dating has always been full of identity fraud. The increasing demand for dating apps has only exacerbated the issues of online dating. According to a study by Psychology Today, half of online dating users have lied about their identity in their profiles. The lack of identity verification when creating an account on the dating app to ensure the digital identity of the user matches their physical identity is also an issue. During the pandemic, catfishing — when a person creates a fake identity online, has increased because lying about an identity is simpler when there is no fear of getting caught. While some dating apps verify the digital identity through other social media platforms such as Facebook, it’s not a bullet-proof system since it’s easy to create a fake Facebook account. These companies must prioritize providing users the best security solution to safeguard the user experience.
More seriously, Tinder and Grinder were under investigation by the government last year after an investigation showed more than 60 cases of sexual abuse of children were facilitated by online dating. This led to a call from government officials to ask the companies to create an age verification system.
There are companies creating solutions to provide identity verification to create a safer community for online dating. Yoti, a digital identity app partnered with DateID, to provide users a simple way to verify the people they are meeting online are who they say they are. However, this is not enough. It is important for online dating companies to deliver a security that users demand by implementing methods of identity verification such as two-factor authentication or biometric authentication, if not, their users may lose trust in the application and cause the company to see a decrease in active users and revenue.
Get involved and join the professional association for identity management that exists to globally foster ethics and excellence in the practice and profession of digital identity. Learn more how to join here.
Want to learn more about identity? Follow IDPro on Twitter and LinkedIn for updates and industry news!
At the 2018 Identiverse® conference, IDPro member Dedra Chamberlin, founder and CEO of Cirrus Identity, gave a presentation exploring the differences between identity management in the higher education environment and a typical enterprise scenario. Given the current pandemic challenges facing identity managers at this time, we thought it would be good to revisit these differences and consider what additional challenges might be coming into play.
In her original presentation, Dedra identified 5 key areas in which identity management in higher education is different than in enterprise:
- Collaboration is as important as competition. Colleague and learner collaboration – often globally – is essential to the success of the university. Conversely, enterprises usually restrict users to only those within the company…outsiders “shall not pass.” This is especially true during a pandemic lockdown. Most university campuses are closed for the remainder of the school year, forcing students, educators, collaborators, and even executives to navigate working from home. This creates new identity management challenges for IT professionals in higher-ed settings.
- Federation means much more than bilateral SAML integration. Rather than simple, bi-lateral federation between two enterprises, higher Ed. Federation are typically multilateral, allowing for global collaborator participation across multiple entities. Enterprises are not traditionally comfortable with this type of authentication and information sharing as it moves beyond their walls and those they’ve partnered with to engage multiple participants . With staff working and teaching remotely, and students needing virtual access, IT teams are experiencing a new type of challenge as video comms tools are more frequently deployed – often with a serious potential for a security breach.
- Collaboration extends to building and supporting open-source software solutions. The higher education need for collaboration on projects and research efforts prompted the development of unique technology frameworks that allow global participation. Enterprises could benefit from deploying similar technologies to better serve and integrate with these communities during these unprecedented times of remote work.
- “External” users are core to the business. Traditional businesses typically have two identity groups to manage: employees and customers. In higher education, there are similarly two groups – “internal” and “external” – with a slight difference. These groups have several participant levels (e.g. internal = staff, faculty, students, etc. and external = parents, continuing ed students, research teams, etc.) resulting in the need for a unique and flexible authentication system that still provides necessary security. Due to COVID-19, the majority of the workforce is forced to work remotely. Enterprises are being challenged to “flex” while still maintaining their required security standards.
- Account life cycle management. Most companies hire an employee and create a corporate account that will track, record, and manage their career information within the organization. Higher education is incredibly different – encompassing phases from application through graduation, departure and return, alumni status, donor, and so on. Individuals need access to certain information throughout the entire life cycle and limiting this could result in complete disconnection – especially challenging for higher education donors. Recently, enterprises are also struggling with this multi-layered experience – employee promotion, role shifting, and in recent cases, adjusting to working from home. The Corporate world could benefit from this nimble management of identity, recognizing phases of a career can be equally as varied as the phases of higher education.
Read Dedra’s full article and share your thoughts with us on this topic. How do you see identity management affecting your enterprise or higher education institution during the COVID-19 pandemic? What expected – or unexpected – challenges have arisen as a result? Share your experience with us on Twitter and on LinkedIn.
IDPro Editorial Committee
It is likely that IDPro members are grappling with providing identity and access management services to a newer type of identity in the enterprise that is not a human, is not purely functional and not always privileged, and may have traits that apply to all – bots. Bots can duplicate human interaction with applications or automate tasks or end-to-end business processes traditionally done by humans. Bot identities need to be available for use by robotic process automation (RPA) software, where the intelligence about the functions the bot’s accounts are performing typically lives. Thus, the bot’s core identity must exist in identity management systems so that bot access is created, reviewed and controlled much like any other worker’s access.
For this article’s purpose, a bot is simply an identity with linked accounts used by software. A bot’s Active Directory account may look a lot like a human’s Active Directory account. Some bots may be deployed with ramped-up functional accounts performing the same maintenance type tasks repetitively on many like-systems – they have a confined scope. Other bots may perform end to end business processes and require the same authentication and authorization services as a human worker to function. Service management platforms need to be able to find bot identity data so that resources can be requested and approved for the bots. Termination, deletion, transfer, certification, separation of duties checks, adequate audit trails, privileged access management, monitoring and a host of other services within the enterprise apply. Each of these services may already exist in an organization for human identities and only need tweaks to make them work well for bot identities. As an example, an inaccurately timed access disablement for a human worker may cause far less organizational stress than an unwarranted access disablement for a bot. A bot owner may have many bots that collectively pose a separation of duties problem for the owner that is more difficult to detect. Identity Governance and Administration (IGA) architectures must evolve quickly to encompass bot identity so that organizations can more safely take full advantage of the new capabilities at their disposal.
The following is a brief list of suggestions for developing basic bot identity capabilities:
- Engage the appropriate teams in discussions about governance and to review access control procedures, audit and compliance requirements, privileged access management requirements, password vaulting, etc. Update cyber policies and standards to include bot identities.
- Recognize bots as a new identity type because it is important to differentiate bots from the rest of the worker population. Being able to identify different populations of nonhuman identities and accounts in the identity data allows the use of those population indicators to determine where the account data should exist and which controls to apply.
- The new worker type should be used to ensure that bots do not automatically pop up in systems, applications, org charts and reports that apply only to people, with unfortunate side effects; bots do not need compliance training, to enter timesheets, get paid or have access to benefit plans. Therefore:
- Have data consumers opt-in to bot data that may be available in data warehouses or other systems that provide data to the organization. Data consumers must make a conscious decision to subscribe to bot identity data if they require it.
- Develop a system or leverage an existing system from which to source bot identities using the new identity type; define a baseline bot identity profile that works for your organization. Use your identity management systems to manage bot account access. (Using bots to manage identity management systems and functions is a fascinating but different topic.)
- Map the bot profile to the user account schema on your major systems and applications. Decide what those account profiles will look like.
- Apply a unique identifier to each bot in enterprises that use a unique identifier for each human identity, to simplify the application of existing identity management and other business processes to bots.
- Create a bot request process in the service management system and enforce consistency in the bot request and onboarding process.
- Tie each bot identity to an approved RPA program as prerequisite to the bot identity creation request. Just as governance and accountability should apply to an RPA program, governance and accountability must apply to the bots that serve them. Wrapping the bot creation process within an already approved bot program adds a layer of oversight and a place to go when follow up on a bot account is needed.
- Tie each bot identity to an owner \ manager during the bot identity creation process; the frontline person accountable for the bot’s existence and access. Have the manager, and a representative of the RPA program the bot is working for, each approve the bot identity’s creation as an added measure of bot population control.
- Add automation to manager changes so that if the manager transfers or leaves the organization a new manager is automatically assigned to the bot.
- Maintain the audit trail including the multiple approvals for bot creation and access. Any additional access provided to the bot also needs inclusion in the audit trail. Going forward, the activity of the bot should be monitored, especially where privileged access is concerned.
- Additional privileged access controls that are applied to people performing privileged access tasks should also apply to bots performing the same privileged functions.
- Certification of bot access and functionality on a schedule appropriate to the functions it performs should be included in the lifecycle.
- Develop an offboarding housekeeping plan to disable and eliminate bot accounts that are no longer needed.
It is no secret that filling technical Identity & Access Management roles in today’s job market is not an easy task. Depending on the role, you may run into a number of different challenges:
- Difficulty finding someone with solid technical experience
- Location strategies narrow down the already small number of qualified applications
- Salary requirements can be out of reach for companies
- Factor in the need for niche skills – vendor specific expertise, new and emerging technology, or even support for legacy technology.
I could continue this list, but to put it simply, everyone who is recruiting is looking for the same type of Identity and Access Management unicorn that you are.
So, what do you do?
Train your own Identity & Access Management Engineer!
Organizations can be successful in reskilling internal talent to fill technical IAM roles if the following criteria are met in partnership between the employee and employer:
- Recognize interest and value for both the employee and the company
- Successfully navigate information paralysis
- Successfully manage setbacks and challenges
Recognizing Interest & Value
Both the company and the employee should benefit from training an engineer on the job. The company benefits by retaining a fantastic worker (let’s be honest, if you weren’t fantastic, you likely wouldn’t have this opportunity), and they save up to 12 weeks of resource time, if not more, by avoiding the onboarding of a person new to the company. The company also saves time and money in recruiting for these hard to fill roles.
You’re likely wondering, how you recognize interest or value in this move for yourself. The answers to the questions listed below were crucial to my success as I trained, on the job, to become an Identity Engineer at Thomson Reuters.
- What position do you want to be in 2 or 3 jobs from now? Or 5 years from now?
- Do you want to do more technical, strategy, or management type work?
- What skills or experiences do people in your goal position have, that you may need to develop further?
- What subjects, type of work, technical areas, or projects energize you in your current role?
- If you choose a broad area, such as Identity & Access Management, what specific area within IAM energizes you or makes you excited?
Pro tip: if you are unsure what area of IAM may be best for you, reach out to the IDPro Slack Channel community; it is filled with many folks across IAM who would be more than willing to share what they do with you.
Successfully Navigating Information Paralysis
Now that you have a goal position, opportunities for growth identified, and a technical area of focus, you’re ready for the next step. But, where exactly should you start?
Pro tip: Get ideas out of your head, keep a list of the subjects you should learn about and refer back to it often.
Have team members review a list of subject areas you have found as learning opportunities; this will give you a sanity check and also give them a chance to provide feedback in terms of priority. Then, have your manager review your learning list.
After your manager has reviewed your list, you’re ready to hit the ground running! But wait – where do you start? What resources do you use?
My recommendations for learning while on the job:
- Focus on no more than 2 information areas at one time
- Job shadow with colleagues
- Narrow down learning resources to what works best for you:
- Books (IDPro’s Annotated Bibliography is a great place to start)
- Online Training & Labs
- Independent Research
Managing Challenges and Setbacks
I have learned a lot of lessons throughout my 18-month journey as an Identity Engineer. Here are a few pieces of advice I would recommend to anyone considering this journey:
- It will be difficult, don’t underestimate that, and don’t get down on yourself. I tend to want instant gratification; this is not the place for that (most days).
- Be patient, it is going to take time. See above.
- The practice of IAM was not built in a day, you’re not going to become an expert in a day.
- Develop a system that works for you in order to see progress. Turn your learning list into a checklist, aim for certifications or specific objectives with timelines to help you feel like you’re moving forward.
- Remember your strengths and continue to use them, you were given the opportunity to move to a more technical role for a reason. Your strengths still apply and add value to your team.
The journey of becoming an Identity Engineer is not an easy one, but it has tremendous value. If you are a manager of an IAM team, I encourage you to take the chance on an employee who is interested in engineering. This journey is just as valuable for you, as a leader, as it is for the worker.
For more detail on this topic, check out my Identiverse 2019 presentation:
How to Become an Identity Engineer: A First Hand Account of Becoming an Identity Engineer on the Job
Alyssa Kelber
Identity Engineer at Thomson Reuters
Today’s protocols and identity practices for web applications are layered on top of HTTP and browser behaviors, which have remained largely unchanged for a long time.
As the use of the web evolves, the proliferation of attacks and the emergence of problematic practices (such as aggressive user tracking from ad platforms) is leading browser makers to introduce new measures to contain those issues. Unfortunately, some identity scenarios are getting caught in the crossfire: as browsers change the “laws of physics” on which protocols and practices rely, existing services and software components will need to adapt or lose their user’s ability to sign in and operate the applications relying on them.
In this article we will discuss one of the most impactful changes on the horizon, the way in which Chrome (and soon after, others) handles cookies in case the SameSite attribute is not set.
SameSite changes impact in a nutshell
Today’s identity flows rely on cookies for two main purposes:
- Keeping track of some information across redirects, and tie it to a particular user agent instance (for example, the Nonce value in OpenID Connect).
- Representing the existence of an authenticated session, typically by emitting a cookie in the domain of the authentication authority (authorization server, IdP depending on the protocol).
Those cookies are often used in cross site protocol legs, where requests go from the authority domain to the app’s, and vice versa.The correct outcome of those protocol exchanges depends on the presence of those cookies in the request.
The SameSite cookie attribute instructs the browser on the circumstances in which a cookie should or should not be sent alongside a request when the domain on which the request originated differs from the destination. SameSite is a relatively new attribute, hence many middlewares and identity providers are not aware of the attribute and therefore don’t set it.
The problem this creates is that starting February 2020, Chrome will change the behavior for cookies that do not explicitly set the SameSite attribute. The new default behavior will be to NOT send cookies with all requests (i.e. the behavior of SameSite=Lax) causing some existing identity flows to malfunction.Firefox will be right behind.
The good news is that the Identirati have been on top of the problem for some time, and nearly every Identity Service Provider in the industry has a plan for guaranteeing business continuity. The bad news is that, if you own a web application leveraging one of the affected flows, you might need to update the identity SDKs to a version that knows how to handle the SameSite attribute.
In the following sections we’ll dig just deep enough to get affected scenarios and remediations in better focus. If you want more details, there’s a growing number of deep dives posts on the internet: we’ll list some relevant links at the end of this article.
SameSite Mechanics and New Default Browser Behavior
Let’s invest a few moments to learn more about SameSite goals and behavior in more detail.
We are all sadly familiar with the cross site request forgery (CSRF) class of attacks. The idea is that a malicious actor can somehow trick the user’s browser to hit a web app where they are authenticated (e.g. they have a session cookie for) and make it perform actions they don’t want, or aren’t aware of.
CSRF attacks are only possible because the malicious requests include session cookies, the artifacts proving that the user has a valid authenticated session. The idea behind SameSite is that by preventing the browser from sending cookies to a domain when a request is triggered from a different domain, the typical way in which CSRF attacks are conducted, the entire class of attacks is mitigated.
The SameSite attribute provides cookie writers various options to dictate in what circumstances browsers should send or withhold cookies to a domain.
- SameSite=Strict determines that a browser will send a cookie for sampledomain.com only if it is already on a sampledomain.com page, or in other words if the request was triggered while the browser was already pointing at the target domain.
- SameSite=Lax will send cookies to sampledomain.com even if the request originated from anotherdomain.com, but only if the request was initiated by a user explicitly clicking a link to sampledomain.com.
- SameSite=None signals to the browser that it’s OK to send cookies to sampledomain.com regardless of how the request originated.
When faced with cookies without any SameSite value set, as of today browsers default to the behavior described so far for None. But as anticipated earlier, around February 2020 Chrome is scheduled to make changes. The new behavior is described in detail here – but in short:
- Cookies without a specified SameSite value will be treated as Lax
- Cookies with SameSite=None must also be marked as Secure (only travel over HTTPS) or will be blocked
Google announced the intent to turn the new behavior on as default in 78 (beta) and Chrome 80 (stable), estimated to be released in February 2020. Firefox already added the behavior as opt in from version 69.
To complicate things: browsers in use today have different ways of reacting to cookies carrying the SameSite attribute, and are unlikely to be all updated to comply with the new behaviors. For example: browsers complying with the earliest SameSite definition will ignore (not send) cookies with any SameSite attribute value other than Lax or Strict, affecting cookies marked with SameSite=None; and WebKit based browsers on iOS version 12 and lower will erroneously interpret SameSite=None as SameSite=Strict. You can find a detailed list of those behaviors in <link>.
This will complicate any remediation strategy we’ll have to apply to preserve identity functionality, forcing identity providers and SDKs to accommodate the different behaviors of multiple browsers- or purposefully forsaking support of some version.
Now that we have a better idea of how SameSite works and what changes are coming our way, we are better equipped to understand what exactly is likely to break in existing identity flows and what remediations are being considered across the identity industry.
Impact on Identity Flows and Remediations
Let’s go back to the two identity flows relying on cookies that were mentioning at the beginning of the article.
To expand on scenario 1, consider the particular instance of a web app implementing web sign on using OpenID Connect and the form_post response type. As part of crafting an authentication request in that style, the web site generated a nonce– a unique value that will be passed to the authorization server and that it is expected to be included, unchanged, in the resulting id_token proving that successful authentication occurred. The idea is that the web app will only accept id_tokens containing a nonce value it recognizes, thus preventing replay attacks.
Here’s the relevant detail: web apps usually save the nonce value in a cookie, so that they can 1) tie to the session with a particular user agent and 2) remain stateless. Normally the cookie containing the nonce is sent to the web app together with the http POST containing the id_token, allowing the web app to perform the necessary comparisons. Today’s nonce cookies are mostly produced without any SameSite value: which means that with the changes described in Chrome 80, those cookies will be considered as SameSite=Lax, and given that the POST originates from the authorization server domain to the app domain, the browser won’t send the nonce cookie… causing the nonce comparison to fail, and the sign in operation to fail altogether.
What’s the solution here? The obvious approach is to modify the logic generating the nonce cookie, typically residing in a middleware or similar component, to carry SameSite=None. That will restore the ability of the browser to include that cookie in POSTs at sign in time.
One extra requirement here is that the nonce cookie must also be marked as Secure and sent over HTTPS, per the new Chrome rules for SameSite=None cookies. That might seem obvious to anyone familiar with how OpenID Connect and OAuth2 work, given that the use of bearer token makes it necessary to perform all communications over secure channels. However, many Identirati are often surprised when learning that applications are routinely hosted on HTTP during the development phase, and many developers aren’t all that familiar with setting up HTTPS. Although as providers we can develop new middlewares and SDKs that set SameSite=None for the nonce cookie, we cannot handle the HTTPS requirements on the developer’s behalf; that is likely to lead at least some developers to abandon standard based flows to less secure solutions, which is why it would be ideal to have browser vendors provide some constraint relaxation in development mode (say admitting SameSite=None on HTTP if the target host is localhost).
The older browsers and the WebKit versions afflicted by the bugs described earlier are also a problem, as their reaction to SameSite=None will be to omit the cookie in the request. Some providers are implementing complex user-agent detecting logic, aimed at determining whether the resulting cookie should include SameSite=None (newer browsers) or not (older browser). The current consensus from the identity community is to circumvent the problem by always emitting two cookies, one with SameSite=None and the other without, at least while the offending browsers aren’t fixed or are no longer supported. The approach isn’t issue-free (platforms generating large cookies are likely to exceed browser limits if they emit duplicates) but it is the best option to date, and the one officially recommended by Google.
The remediation discussed here is largely aimed at web apps and the SDKs/middlewares used to implement web sign on, and in particular the ones using form_post response type (the ones leveraging full page redirects and the authorization code flow for the same purpose aren’t affected).
Let’s also look at scenario 2 in which case an Identity Provider writes a cookie representing the user’s authenticated session and the application uses that cookie via an iframe to refresh the applications tokens. A key aspect of the SameSite processing rules is that cookies marked as SameSite=Lax are NOT sent when requests occur in iframes unless the domain main page and the iframe are the same which is NOT the case for the identity flow referenced above. This affects any Single Page App (amongst other scenarios) that may be using a hidden iframe with OpenID Connect prompt=none processing to refresh tokens within the app. At the time of this article, the only remediation is for the IDP to set the SameSite=None attribute on its authentication session cookies. This is less than ideal as it creates a security exposure for the IDP by allowing those cookies to be sent in 3rd party contexts, increasing the likelihood of CSRF attacks.
The Future
This is not the end of changes coming from browser vendors as can be seen by the Intelligent Tracking Protections initiated by Apple as implemented in Safari and other browsers. While ITP is focused and removing the ability of 3rd party advertisers from tracking users across the web, it can have unintended consequences for some Identity flows as well. Discussing these changes in detail is outside the scope of this article though we highly recommend reading through the additional information provided via the included links. Additionally, there are recommendations from the browser vendors to change the way browsers manage state via HTTP State Tokens and also thinking around how browsers can better manage a user’s signed-in state. These topics are also outside the scope of this article but additional links are provided.
Conclusion
If you’ve made it this far, thank you for reading through to the end! The final and primary recommendation is to review any identity related flows in your system to determine if they will be affected by the SameSite changes and make sure to take action before the February 2020 deadline.
Additional Information
Recent Presentations and Blog Posts
OpenID Foundation Workshop: Browser Changes impacting Identity Flows
Intelligent Tracking Protection
Web Tracking Prevention Policy
Browser Vendor Proposals
Managing SignedIn state in the Browser
Combating Fingerprinting with a Privacy Budget
Vittorio Bertoccio
Principal Architect at Auth0
George Fletcher
Identity Architect at Verizon Media
Executive Summary
Starting in 2018, IDPro executed two annual skills surveys in order to share with the digital identity management industry who its practitioners are and where their interest lay. Through these surveys, IDPro has determined that:
- A major of practitioners share five areas experience
- The feeling proficient as an identity practitioner is a long journey
- Enterprises’ interests and individuals’ skills sets are often well aligned
- Enterprise near-term priorities align with individual interests in some areas
- Misalignment between enterprise near-term priorities and individual interests present opportunities to both
Message from the President
I am thrilled to be able to formally share the results of our skills and program survey with you. To date, no organization has conducted such a study of our industry and our practitioners. When we founded IDPro in 2017, it was part of our vision to help digital identity practitioners learn from other practitioners and this survey is part of that vision.
The results of our survey are important for individuals and organizations alike. Individuals will find which technical and non-technical skills other practitioners found useful in their careers. Organizations will learn which of their priorities align with practitioner’s experience and interests. Both will learn where the growth areas of our industry lie.
This report is our first pass through the survey data. There is more we can and will do over time – we have our own ideas, but we are also keen to understand from members and non-members alike how we can most usefully develop the survey. That said, this is a meaningful start and I look forward to expanding the effort in future years.
— Ian Glazer
Founder and President, IDPro, October 30, 2019
If every year is The Year of PKI, then when exactly was The Year of Two-Factor Authentication? Was it 2012, when the epic hacking of Mat Honan highlighted just how vulnerable all of our digital lives are? Was it 2014, when the even higher profile iCloud leaks of celebrity photos pushed various consumer services to hastily make two factor authentication an option available to users? Or did it really arrive in 2018, at least for financial institutions, when PSD2 delivered a regulation with some real teeth?
The Struggle is Real
Two-factor authentication (or 2FA as the cool kids call it) isn’t really new. We’ve all experienced it during the course of our professional lives, but organizations still struggle with rolling out 2FA to customers. Why? The simple reason is that while employees are a captive audience that will submit to whatever painful, inconvenient mechanism you force them to adopt (ok, except for MDM on their personal phones), customers are a whole different ballgame. The customer experience matters, and if you don’t do it right then people are either going to not enable it (when you make it optional), work their way around it, or not engage at all.
For any organization starting down the path of implementing 2FA, it can be confusing and challenging. They find a large list of factors spread across the “something you ___” categories, but little guidance on how to put a good 2FA scheme in place. Most organizations simply end up taking the approach of picking an additional factor that they can simply tack on to the end of their password authentication step, and call it a day. Unfortunately, that simplified approach falls far short of successfully addressing the problem.
A Framework for Designing Your 2FA Schema
I first started going down the 2FA rabbit hole when I wrote a blog post analyzing the Mat Honan hack. Since then, I’ve had the benefit/privilege/misfortune (which one it is depends on the kind of day I’m having) of having worked on strong authentication models quite a few times. More recently in my current role at Uniken, our efforts to create a multifactor authentication model that is focused on the customer experience, and can work across industries for both small and large organizations, user bases and threat models, has yielded some deep insights into what works and what doesn’t when it comes to 2FA. The effort to distill these learnings into something that can be explained to our product team and our customers has resulted in a basic framework for how organizations should go about implementing 2FA for their customers, built on 6 pillars.
Viability
The first pillar of that framework is Viability. When going through the long list of factors possible, you have to assess which of those factors is viable for your 2FA scheme. Assessing viability has multiple considerations:
- You have to think of the people that make up your user base, and what factors they’d be willing to accept and use.
- You also have to think about the cost of the factor, and whether that is a cost that the business will bear, or the customer will bear. Hardware tokens are great, but expensive. Is the business buying it for their customers, or are they expecting the customer to buy it themselves?
- You have to carefully consider the threat model associated with the factor. The Yubikey is a really secure authentication factor, where the user has to plug the key into a port on their desktop in order to authenticate. But research studies have shown that people will often leave them plugged into their desktop even when they leave the office, virtually negating its assurance as a possession factor.You have to think of the people that make up your user base, and what factors they’d be willing to accept and use.
- You also have to think about the cost of the factor, and whether that is a cost that the business will bear, or the customer will bear. Hardware tokens are great, but expensive. Is the business buying it for their customers, or are they expecting the customer to buy it themselves?
- You obviously have to consider the effectiveness of the factor. See: security questions.
- In many cases, regulatory compliance can enter the equation, since regulators are increasingly rendering opinions on which factors are acceptable for your business.
Multimodal
The second pillar of the framework is Multimodal. When implementing two-factor authentication, the goal is to have each user employ at least two factors when authenticating (obviously). However, that does not mean that the business is only going to support two factors. Not all factors work for all users, and when you’re trying to increase the number of customers turning on 2FA, you have to offer options that work with your vast and diverse user base. The idea that you can find two factors that work for everyone leads you to a least common denominator approach, and that’s how we got SMS OTP as the de facto “standard” in 2FA, and a weakening of the security model. Offering choice allows you to address the varying capabilities, preferences and circumstances of your end-users, and avoid a “one size fits all” approach that alienates customers and often weakens your security.
Adoption
I’ve alluded to the third pillar, which is the one that is the most misunderstood – Adoption. The reality is that unlike enterprise environments where you can mandate 2FA, the customer environment requires you to actually convince your end-users to start using 2FA. There’s a wonderful research paper called “Why Johnny Doesn’t Use Two Factor” that I highly encourage everyone to read. While there are many important takeaways in the paper, one overarching lesson from the paper is that organizations need to make UX research a core element of their IAM program, especially as they design their 2FA scheme. It’s a critical and foundational element to creating the right set of messaging, training, and incentive components that you will have to incorporate into your roll out plan to drive adoption.
Omnichannel
An overlooked pillar is Omnichannel. Businesses have often failed to recognize that 2FA shouldn’t apply just to their web or mobile channels, but must be deployed across all their customer facing channels. Businesses are engaging with customers and partners across many channels – web, mobile, call center, in-person, chat, smart home assistants, and more – and each channel usually brings a completely different way of authenticating the end-user. That inconsistency frustrates your end-users, creates a headache for your customer-facing staff and IT staff, and delights bad actors. Attackers look for the weakest link across those channels, and go after that one, exploiting not only the weakness of the channel, but also the frustration that your customers and employees feel. The result is rampant account takeover attacks and fraud. Businesses have an imperative to transition away from an inconsistent hodge-podge of varying authentication models, and bring some consistency and equality of security levels across their various channels.
Processes
The fifth pillar of the framework is the one that most organizations don’t pay enough attention to – Processes. Enabling and maintaining 2FA for individual customers involves many different processes, each of which needs to be properly designed:
- Enrollment: If the enrollment process is flawed, the assurance of your 2FA is suspect from the very beginning. Many organizations will allow users to set up their second factor after they’ve authenticated solely using their first, and that is a massive vulnerability point in your scheme.
- Backup: No authentication factor is immune from loss or destruction, so you have to think about ways to not only allow, but proactively encourage, your customers to set up additional authenticators as backups. And those backups better have the same strength as the primary, otherwise you’re creating a backdoor for attackers.
- Escape Paths: Not all authentication factors are always available for use. Consider what happens to push notification based authentication for someone working in a part of the building, or on a plane, where they get no signal. Locking them out under those circumstances can be hugely problematic.
- Recovery: Consider how you will support an end-user that has lost their authentication factor(s), so that they aren’t faced with the dire consequence of being permanently locked out (think of all the horror stories of bitcoin wallets irrecoverably locked up because their owner lost the hardware token containing their private key). Recovery paths must also be designed properly to avoid having them turn into backdoors for bad actors. And for heaven’s sake, never use an authentication factor as the verification factor for also doing recovery. I’m looking at every service that uses SMS OTP as a second factor of authentication, and also as a way of resetting a forgotten password. You’ve effectively created a backdoor that turns your two factor authentication scheme into a one factor authentication scheme.
- Deprovisioning: Of course, you have to consider how one can go about invalidating a factor that is no longer available to the customer, or is no longer acceptable to the business because of vulnerabilities or issues discovered in it (whether it be at an individual level or system wide).
Importantly, escape paths and recovery flows need to be treated as exceptions with higher risks associated with them. That often implies increasing the risk evaluation and security of those flows, which often means adding friction. However, customers are frequently understanding of the increased scrutiny in those paths (provided you’re explaining it to them).
Trusted Environment
The sixth and final pillar of the framework is establishing a Trusted Environment within which to execute 2FA. It won’t really matter how good or strong your factors of authentication are if the environment within which those factors are being accepted, stored, transmitted, and evaluated is compromised, allowing them to be stolen, manipulated or replayed. Keyloggers that capture secrets, malware apps that intercept SMS codes or steal keys, malicious WiFi, reverse proxies, and rogue cell towers that capture and replay credentials or tokens – threats like these reduce the effectiveness of 2FA and degrade organizational trust in those factors. Your two-factor authentication project has to be part of a larger security program that enforces defense-in-depth (or, to use the industry term du jour, zero trust security) to not only leverage the factors of authentication, but also look at the health of the devices and hardware being used and the networks being relied upon, as well as other signals of risk, in order to build trust in (hopefully) the simple act of authenticating your customer.
So, there you have it. A simple framework to apply while designing, building and rolling out your two-factor authentication program. May all your authentications be strong, and all your customers be happy, engaged and protected.
[This article is adapted from my talk at EIC, Identiverse and Identity Week. You can watch the Identiverse talk here.]
Nishant Kaushik
CTO, Uniken Inc.
Everyone has a smartphone (in fact, many have more than one). Nobody wants to remember yet another password. Surely the combination of these two means that the smartphone app is the logical solution to securing authentication and delivering a truly passwordless experience for both employees and customers? Unfortunately, it’s not always as simple as that, though. In the ongoing war between convenience and user experience on the one side, and strong security and privacy on the other, we need to ensure that we do not unwittingly create new risks and attack surfaces in our rush to remove passwords.
The Trouble with Passwords
It’s probably not all that controversial to say that we, as an industry, are not doing knowledge- based authentication (and passwords in particular) at all well. Knowledge is fallible and unreliable – just because somebody knows a particular random string of characters at one point in time is unfortunately no guarantee that they’ll remember that same thing days, months oryears later. Bad password hygiene thus abounds, as individuals would rather use weak passwords to eliminate complexity and improve their own user experience. Companies often counter by enforcing impossible password policies that only make the user experience worse.
Smartphones are commonly used today as a secure yet convenient second factor, for a number of good reasons. Phones offer built-in private keystores protected with a biometric and a built- in way to deliver secure authentication challenges via push messaging. Smartphone apps often double as a soft token, and organizations can stay in control of the user experience and branding of the app. They are also cheaper and more convenient than hard-token based solutions
Are we ready, though, to abandon passwords entirely and rely solely on the smartphone as a way to authenticate users? I believe that we certainly can do this now.
The Boy who Logged In using (only) his Phone – with apologies to JK Rowling.
A number of techniques and patterns exist today for enabling authentication using only a smartphone. There are, of course, pros and cons to each of them.
Identifier + Push is one technique that I’ve seen. This is where the password is dropped entirely, with the user instead only providing a username (which can, of course, be cached in a browser cookie). Once the user has been identified, a push notification is sent to the smartphone app in order to authenticate the user through the possession factor. In order to implement this model securely (and not reduce security to single-factor, possession only authentication), it is strongly advised to ensure that a biometric login or approval is required on the mobile in order to accept the authentication request.
Claiming an authentication session through scanning a QR code is another popular approach – one that has the added usability bonus of removing the username entirely. In this model, the user opens a trusted app that is strongly linked with her identity, uses a biometric to unlock her private key, and then scans a code that is presented by the website she wishes to access. It’s agreat and novel approach to the problem but can lead to something of a proliferation of different authentication apps on the phone. Some level of user retraining may well be required, too.
Native app auto-login is a good approach for passwordless authentication when the user’s journey starts on the smartphone itself. Once again, the combination of possession (a private key within the app) and inherence through a biometric can be used to enable login without requiring users to type in usernames and passwords each time they launch an app.
Across the industry, we continue to evolve and develop new standards to improve authentication and two newer options for passwordless authentication have emerged from the identity standards community – each aiming to tackle the problem in different ways.
Client-Initiated Back-channel Authentication, or CIBA, is a new standard from the OpenID Foundation that complements the existing redirect-based OpenID Connect flows with a decoupled option that uses a push to a smartphone app as the primary means of user authentication. CIBA is still emerging but offers a solution to a wide variety of use cases, moving beyond authentication towards transaction approval as well.
The new WebAuthN standard developed under the auspices of the W3C provides an end-to-end secure flow for user authentication with a high level of resistance to phishing and man-in-the- middle attacks. Central to the approach is the Client-to-Authenticator Protocol (CTAP) that enables a user agent to communicate with any authenticator device that implements thestandard. Google’s latest phones incorporate a built-in CTAP authenticator, allowing the native biometric capability of the device to be used as an authentication factor.
With Great Power comes Great Responsibility
I do need to end with a few caveats, though. While the approaches outlined above all offer a far better user experience than anything based on passwords, we do need to take some key points into consideration. It’s a pretty small leap from “My Phone is my Password” to “My Phone is my Identity” and it thus becomes very important to include a strong process of identity proofing in any enrollment process that allows enablement of a smartphone app as a primary authentication factor. As the smartphone becomes the primary authenticator, it is equally important to ensure that possession of the smartphone alone is not sufficient to allow access; a biometric or knowledge step must always be added to the authentication process.
Some of these approaches are reliant on standards that are not yet implemented consistently across mobile operating systems and/or browser ecosystems; others rely on the user installing ‘yet another’ authentication application on their device, which can mar the user
experience. Both of these situations will improve with time, but for now, take care to pick solutions which are appropriate for your target user base.
Finally, we need to be realistic about the risks and vulnerabilities of a smartphone-app-based approach to identity and security and ensure we are implementing the necessary countermeasures to protect our users against the threat of compromise of their mobile keystores. This starts with detection of rooted or jailbroken devices but should also encompass an appropriate level of malware detection and anti-tampering counter measures.
(For additional background, check out Rob’s Identiverse presentation on this topic)
Rob Otto Office of the CTO Ping Identity
Everywhere you look on the internet today, the chances are good that you’ll see an API-driven application. And where you see an API, the chances are even better that there’s an OAuth 2.0 authorization server protecting that API. A standard published in 2012, the OAuth 2.0 delegation protocol has been a gift to software developers across the web: it provides a powerful and flexible standardized security mechanism which, in contrast to many security protocols of the past, is relatively easy to get right. As a consequence, it has become wildly successful, and is an essential tool in the toolbox of a modern API developer.
But here in 2019, we’re really starting to see the edges of what OAuth is good at. There have been many extensions to OAuth 2.0, some of which protect specific parts of the process like PKCE for mobile apps, JAR/JARM for front channel protections, and PoP/MTLS for token presentation. Other extensions have added new ways to do OAuth, such as the device flow and CIBA. The prevalence of such extensions speaks to OAuth’s flexibility, but the landscape is getting harder for developers to navigate. New styles of client and server deployment, new security threats, and new expectations from both end-users and developers have all pushed the OAuth framework into spaces it was never designed for, and the results can be overwhelming. In the last few years, I’ve been looking at this landscape of options and attempting to draw out some of the commonalities of the various OAuth 2.0 extensions into a new abstraction that learns the lessons of OAuth 2 without carrying its hard-earned baggage.
Some of OAuth’s biggest problems come from its overuse of the front channel for passing essential security information. While front-channel redirects are an essential innovation in allowing interactive user consent, the way OAuth 2 uses these redirects leaves it open to a variety of alteration, injection, and data leakage attacks. But this begs the question: does the protocol need to put all of that information into the redirects in the first place? We can get around it by using the “Intent Registration” protocol design pattern. If the client makes a back-channel call directly to the authorization server first, all of the sensitive information for the authorization request can be passed directly between the client and the AS without going through the browser. The AS can return a reference that the client can pass to the browser that represents the sensitive information, instead of carrying the information itself.
This step creates a transaction between the client and authorization server which can be augmented, mutated, and adapted over time as new information is made available and decisions are made. If the AS decides from this first call that it doesn’t need to talk to the user, then it can return an access token immediately. If it instead decides that interaction is needed, the client and AS can signal to each other the ways that the interaction can take place. In OAuth 2, each of these paths has to be managed and chosen up front through selecting the grant type, response type, scopes, and extensions to the OAuth 2 protocol in play.
Since we’re pushing information upfront, this transactional approach gives us a chance to describe resources more richly than OAuth’s scope strings allow us. We also have a chance for the client to present and bind keys to the transaction, allowing a stronger association with the client software even when using ephemeral keys with mobile applications and single-page apps. Instead of basing all of our trust on a pre-registered client system, which is what OAuth 2 is optimized for, we have the ability to base our trust on a variety of policy mechanisms that fit different types of applications much better.
Finally, we have an opportunity to use these patterns and capabilities in a space beyond authorization delegation. For example, let’s say you have a process where most of the time you want your API calls to function without hindrance, but once in a while, you need to interact with the user to get additional information, like an updated credit card number. This transactional pattern allows us to rethink how we approach authorization and access to our APIs.
The XYZ project (with information available at https://oauth.xyz/) is a concrete proposal for how we could do all of these things in a new protocol that is based on the concepts of, but not compatible with, OAuth 2.0. I’ve presented XYZ at the Identiverse Conference (https://www.youtube.com/watch?v=U9i7YaN8v9c) and the IETF OAuth Working Group (https://www.youtube.com/watch?v=TE3Fzb5-Jz0&t=3764), and the conversation is starting to pick up in the IETF with the TXAuth mailing list (https://www.ietf.org/mailman/listinfo/txauth).
The IETF will be discussing this at the TXAuth BoF session in Singapore on Monday, November 18, 2019. You can participate remotely via the links for TXAuth at https://datatracker.ietf.org/meeting/agenda/#txauth.
Justin Richer
Bespoke Engineering LLC
Hi! As a follow-up from my presentation at Identiverse, I wanted to share my thoughts about the blurring boundaries between IAM and CIAM in this blogpost.
In a world where the network boundary no longer ends at the corporate firewall, identity has become the central mechanism for securing, managing, and enabling experiences that help businesses work more directly—and more productively—with all their constituents: employees, vendors, suppliers, partners, and customers. Today, whatever relationship a person has with a business, they can connect to it anytime they want using the device of their choice and a wide range of SaaS applications. But this didn’t happen all at once.
When we dropped the boundaries around the corporate network, IAM solutions helped us manage employee access to resources and apps the same way we did when everything was on-premises. The increased flexibility and internal productivity of this model were so beneficial that employees wanted to work the same way with their business partners.
At first, the only way to give partners access to apps, collaborative spaces, and business data securely was to create an organizational account for each partner employee. These accounts had to be managed and secured. Someone had to create each account, onboard the user, perform helpdesk tasks like resetting forgotten passwords, and retire unused accounts. With B2B IAM solutions, we can now support collaboration with less management burden by giving external users access to resources based on the work identity from their organization.
This was a great step forward, but we also wanted ways to better engage with customers, particularly those using mobile devices. This meant publishing web and mobile apps with beautiful, tailored user experiences. But, as with B2B, allowing each consumer to create an account would increase the management burden. The business would also become responsible and liable for protecting customer accounts and the information associated with them. Customers, for their part, would have to keep track of another username and password.
CIAM solutions make it possible for consumers to use their social identities to sign up, set preferences, stay in contact, and make purchases. They not only reduce the management burden and liability for businesses, they enable powerful scenarios like using CRM systems to keep track of customer interactions and purchase behavior, which helps businesses improve products and services, target marketing more effectively, and customize offers.
Meeting people where they are: the next evolution in identity
Identity has made great progress. We now have solutions addressing the core business scenarios of making employees productive, collaborating with other organizations, and engaging with customers. But we’re now dealing with constraints and complexity because each of these solutions supports a different scenario with a different technology stack. Since IAM solutions for B2B are optimized for extending the employee experience to partners, they focus on security management, access management, lifecycle management, and built-in governance. CIAM solutions, which are optimized for enabling consumer engagement, focus on customized, branded experiences that are largely self-service.
These separate solutions extend IAM capabilities, letting us recognize individuals to give them secure access to apps and information they need. Although they weren’t designed to work together, they’re more similar than most people realize. So, why keep them separate?
- What if we want to make it easy for business partners to collaborate with our employees, but we want to support self-service, so we don’t have to be their helpdesk?
- Can we set up a customized, branded portal that shows business partners all the resources they have access to in one place?
- What if partners are too small to have an IT department? Can we let them sign-in with their own email address or a social ID the same way I let consumers sign in with theirs?
- What if partners do everything via phone apps and never use email? Can we let them sign-in with their phone numbers?
Because the above scenarios mix components of IAM and CIAM solutions, customers get confused about which stack to adopt, and what they choose may not have everything they need. What if, instead of a different solution for each type of business relationship, we had a single solution that meets people where they are? In other words, what if the solution centered on the individual and all the types of relationships they may form with an organization?
When it comes to people and their relationships with a business, most don’t have a single role: employee, business partner, or customer. They may be a business partner in their work life and a customer in their consumer life. They should be able to sign into an experience using a single identity, select the appropriate role, and switch experiences by switching roles.
Here’s how this could look:
| Natasha engages with Woodgrove Title Insurance both as a real estate agent and as a homeowner. | |
| She signs into the Woodgrove Title Insurance portal using her Gmail account as her username, which is also her Google ID. | |
| When prompted to select her role, she selects Registered Agent. | |
| She now sees the Woodgrove experience customized for the real estate broker she’s associated with, Fabrikam Residences. From a dropdown list, she can switch to her consumer role as a Home Protection Plus customer. | |
| She then sees the Woodgrove experience that’s customized for consumers. |
This is just one type of rich experience made possible by combining the collaboration functionality of IAM for B2B with the customized user journeys enabled by CIAM. Other possibilities include relationships with an organization that change over time.
For example, individuals start their college careers as applicants. Once accepted, they become prospective students. Once they matriculate, they’re students, and once they graduate, they’re alumni. If they take graduate courses, they become students again. If they take a teaching assistant position as part of their graduate studies, they’re now students, alumni, and employees.
An individual interacts with their university in a different way in each of these roles. With a holistic external identities solution, the university can provide a custom experience designed for each of these relationships.
To enable such scenarios, we need an identity solution that meets people where they are. It must accept identities from many sources and allow organizations to build secure, customized user journeys and experiences based on the relationships they have with other organizations and individual people. The identity solution needs to be flexible, so it can accommodate the future.
Because the boundaries between the different relationships individuals have with organizations are blurring, the siloed solutions we have today aren’t flexible enough to carry us forward. Trying to fit individual people into an IAM or CIAM bucket just doesn’t work. We need to meet people where they are.
It is therefore a perfect time for you to evaluate if the identity journey in your organization meets people where they are!
For example –
Consider embracing Bring Your Own Identity (BYOI) if you’re still creating accounts for customers or allowing them to create accounts, as that adds business risk.
Make sure to deeply understand your branding needs and find a solution that is flexible.
Make sure you can partner with organizations of all sizes, from mom and pop shops to large businesses.
Offer experiences that are intuitive and contextual that helps users understand what they’re doing and in what context they’re taking actions.
In short, are you meeting your users where they are?
I’m extremely excited about this vision! If you have scenarios that you’re trying to achieve in your transition towards digital transformation, I’d love to hear from you! Let’s talk!
Sangeeta Ranjit
Principal Program Manager
Microsoft Corporation
It’s a well-established fact that experiences color our reactions. A good experience can turn a chore into something delightful. A bad experience can make even a favorite activity downright unpleasant. Good experiences tend to make us want to come back for more – you can thank dopamine for that! – so given that the identity experience is often the first thing that we encounter when we try and interact with an online service, it behooves any business, whether consumer or business facing, to make this experience as good, as unobtrusive and as delightful as it can be.
All too often, that isn’t the case.
I suspect that, as digital identity professionals, we tend to notice failures more readily that others, but take a moment and consider how frequently in the last month you have registered for a new online service, or needed to confirm your identity for a high-assurance use-case, or – my personal favorite – changed your password. I wonder how many of those interactions were at the very least ‘not too bad’? How many were ‘pretty good, considering’? How many were ‘surprisingly good’?
I’m prepared to bet that the majority were ‘not too bad’, with maybe one ‘Wow! I wish everyone did it like this’, seasoned with a reasonable scattering of ‘!@*$#(@ that was dreadful!’ (after an hour of back and forth trying to get the thing to work).
Businesses can and should do better.
We have the standards, processes, procedures and products to make these interactions both secure and convenient. By secure, I don’t mean: hey, we made it really hard for you to generate a new password that conforms to our arbitrary ‘rules for good passwords’. And by convenient I don’t mean ‘forgot your password? No problem, we’ll send an email (to your address, which is your username) with your new password in the clear.’ The first of those is so depressingly frequent that I can guarantee everyone reading this will have had that experience in the last 30 days. The second is sadly still more common that you might imagine.
No: by secure and convenient, I mean identity processes that are designed to help us, as human beings, get on and do the things we need to do, in the certain knowledge that our information and our privacy is being protected.
So, if we have all we need at our disposal to make this happen, why then are there still so many poor experiences? As ever, it’s a combination of things. Business owners don’t realise that this is a problem. We don’t instrument it (and in some cases it’s truly very hard to instrument), nor we do focus groups, so we can’t demonstrate the effect on the business. Security teams don’t know any better. We’ve trained consumers to understand the wrong things as ‘secure’. And users don’t complain, either because they don’t think they can or because they can’t imagine a better alternative.
Identity pros know better. We know how to build these systems better. We know we can make a positive difference to the businesses we work for and keep those businesses and our customers safe. We know that these are not competing requirements; they are complementary.
I’ll end, then, with two requests. First: if you recognise that these are problems in your own organisation, start the conversations to help make a change – and remember that those conversations likely need to start as business rather than technical discussions. Second: share with your fellow professionals what works and what doesn’t; and ask for help where you need it.
In identity, as in everything else, the experience matters. It’s time to make it better.
Andrew Hindle
Independent Consultant
Board MemberIDPro
All I Needed to Know I Learned from Clooney, Pitt, and Damon: Using Ocean’s Eleven to Start an Identity Community
Recently, on a flight over some distant ocean (it matters not where), I had the opportunity to re-watch Ocean’s Eleven for approximately the 1,623rd time. It’s the classic heist movie: a small group of people with a plan — and a killer soundtrack — craft something extraordinary. As the high-oxygen environment deepened my insight, I realized that it was also the blueprint for something no less ambitious: starting your own identity-focused meetup.
In the summer of 2018, Mike Trachta, David Lee, and I started just such a gathering in the Austin area. What follows is a pairing of our experience and Hollywood-produced cinematic excellence. While our experience may not be universal, the hope is that it would inspire you to create your own local identity community. (Note: it may help to visualize us as looking like Brad Pitt, Matt Damon, and George Clooney for the duration of this article. We’re onboard with that.)
Obviously, for this approach to be intelligible, you have to have seen Ocean’s Eleven at least once. Given the box office statistics, most of humanity has by now — but if you’re one of those that somehow missed it, go fire up your streaming service of choice and watch it.
No, really. We’ve got nothing but time here.
All done? Great. Let’s get started.
First, we’re going to need that soundtrack I mentioned before. Find it, and before you read any further, fire up the first track, “Boobytrappin.” Feel the groove and let it be your guide to identity success. The rest of the songs from the movie will lead us through a five-step process. As you read each step, play the associated song for inspiration and a deeper understanding of the concepts in play.
Get a Core Together
“Ten oughta do it, don’t you think? You think we need one more? You think we one more. Alright, we’ll get one more.” Aside from being the best line from the movie (fight me), George Clooney highlights the key first step: pulling together a core group of people.
Building a community can be a difficult task, and it becomes much easier with a small group to share the load. In July of 2018, Mike, David and I got together several times for drinks and dinner with the common goal of starting up a group associated with IDPro. This gave us time to understand our individual strengths and to figure out what we wanted the group to look like. After a few meetings, we figured out that we wanted to have solid identity content with good networking potential — and that we wanted it to reflect Austin culture as much as possible. That meant a relaxed agenda and attitude; we also recognized that our original ideas would evolve over time, which freed us up from feeling like we had to determine everything up front.
Our advice would be to get a core of at least three people together who want to see a group become reality. Over the course of the past year, it’s been helpful to have more people available to help host — especially as conferences or other travel pulls us away from Austin. Adding others along the way who are interested in helping out can spread the burden further and bring new energy and ideas. This happened for us with the delightful addition of Catherine Schulten in May of 2019.
While we wanted to prevent being locked-in to any set ideas, we also realized that a coherent plan would be helpful, which is what we built over the course of a rye old-fashioned (or two) and bar food.
Develop Your Plan
Three Casinos. The best security and safes in the world. A difficult target, but with a plan, anything is possible. Creating a new identity meetup is a challenging prospect that becomes more manageable with a concrete strategy.
As we laid out our proposal for the Austin Identity Professionals Meetup, we wanted to keep it simple and achievable. We settled on meeting once a month, with a rotating location (using WalMart’s Technology center in downtown, and out by the lake at SailPoint’s main offices.) This sponsorship gave us a jump start on the process — rather than having to crowdsource our funding, we were able to demonstrate the potential value to our employers.
As far as the content, we knew that there were enough identity-minded people and technology companies to support a quasi-regular guest speaker. We’ve had a talk about MFA from (Yubico), a discussion about usability from Wendy Nather (Duo), along with a few other guests. Education and growth were the primary goals rather than, say, hawking a product or a singular approach to a problem.
Planning the actual meetup is not rocket science; having a time, place, and topic or speakers lined up are table stakes for getting a meetup off the ground. It also helps to have something to make the time spent together more enjoyable, like lovely beverages and food — it worked well in our original planning sessions, and so we incorporated it into the group meetings also.
Eat, Drink, and Be Brad Pitt
Mr. Pitt eats in almost every role he’s been in, and Ocean’s Eleven is no exception. In fact, in one particular scene he consumed forty two shrimp during filming. His voracious method acting is a reminder that free food and drink attracts people like a pristine overlook attracts “influencers.”
Content and networking were components of what we wanted to create, but community was first and foremost. Free foodstuffs meant that people would come earlier and leave later, that they would have more time to be known within the group. The community would grow more rapidly when properly fed. It is a universal truth that people cannot live on identity alone.
In short, be like Brad. Food and drinks are not optional in our opinion, and constant eating may launch you into an international career in film. (That last part might only apply to Mr. Pitt.)
Market All the Things
This song can be summarized in a single word: infectious. It will be in your brain for a few days, and you’re welcome for that. That kind of memorability is your goal for your group — publicity and marketing is your friend when attempting to create a new identity community.
In Austin, we’ve tried different publicity routes with mixed results. We have our own meetup site, which helps with coordination and discussion for people interested in coming. We’ve promoted it on Twitter, LinkedIn, and various other social media sites as well. Ironically, I’ve found that the best route to adding people to the community is through personal connection and invitation; you know more people than you think, and inviting them one by one is a good route to building up a group rapidly. By and large, we have decent attendance — we average about twelve to fifteen people per meeting, with high water marks of around thirty at particular times of the year.
People can’t join your gathering unless they hear about It, and they won’t hear about it unless you put the effort into publicizing it. That publicity opens the group up to growth and change.
Be Open to Change
Ocean’s Twelve, Ocean’s Thirteen, Ocean’s 8 Soundtracks
Ocean’s Eleven, despite being a remake, was a hit. So, what did they do? They did what anyone would do in their position. They made sequels. And then they made a sequel of sorts with an all-female cast: Ocean’s 8. All of these were successful, with some claiming that Ocean’s 8 was the best of the group.
These variations in plotline, theme, and casting choices illustrate that change is not something to be feared, but rather to be expected. Your original plan will likely need modification at some point. Set a period of time – say a half year, or a year — to reevaluate what is working and what’s not. We’ve had to do this a few times over the past year, delaying meetings, changing format depending on speaker availability; we’ve felt our way along, and we’ve enjoyed our times together because we haven’t been chained to a format set in stone.
That flexibility leads to the final step in creating an identity community, independence.
Don’t Follow My Advice (Completely)
Ok, I . . . misled . . . you in the opening. There are actually six steps to success. This last one is counter-intuitive, since I just wrote a thousand words on how to build an identity meetup.
Our experience is helpful but not necessarily proscriptive. There is no one set way to start up any group hangout. Starting an identity community is like having a baby — they are all unique. Our meetup looks different than those across the country — and each one should be customized for their local environment.
Take lessons from what we (and others) have created, and then go and build your own without trying to crowbar your reality into a preset mold. Your identity meetup is not defined by form or function, but rather by the group of people that comprise it. Do what works for your group, at your time, and in your location.
Let the melody of this track wash over you and consider the end of Ocean’s Eleven. After all of the lines are spoken, all of the food is consumed, and the music slowly dies away, the members of the group wander away one by one into the “real world,” enriched by their experience together. May your identity gathering do the same for your community.
Mike Kiser
Global Strategist & Evangelist
Office of the CTO
SailPoint
_____________________________
[1] The author does not hold this position, as he regards the first remake of Ocean’s Eleven to be the high-water mark of these films.
2It must be noted, however, that some babies are, indeed, ugly. But not your baby, of course. Never yours.
On June 3rd during Apple’s WWDC 2019, Craig Federighi, Senior VP, Software Engineering for Apple revealed a new social login solution alongside Facebook Connect and Sign in with Google. With Sign in with Apple, Cupertino’s firm aims to revolutionize social login by elevating the personal data protection level and allowing end-users to control the data they share with applications.
Privacy and data control at the core
Sign in with Apple (SIWA) works just like its competitors: the end-user chooses to authenticate with their Apple account and then consents to share data with a third app. It is precisely within that last step that SIWA aims to bring more trust. The end-user will be able to not only view the data being shared, but also the actual values. Moreover, Apple brings the possibility to protect end-users from spam and some cross-referencing techniques by sharing a randomly generated email address in place of the usual one. This random email will act as an alias and could be disabled at any time the user chooses.
The authentication actually uses the end-user AppleID and is already integrated to all Apple devices making biometric authentication (ie TouchID or FaceID) available as well as push notifications. Apple indeed underlines the fact that it makes it easy to implement MFA for third party apps.
With Sign in with Apple, Apple directly aims at Facebook and Google by proposing a privacy-preserving technology and by getting a foot in the door through its AppStore policy: every application using social login features must include Sign-in with Apple within the options.
For now, the update is sketchy but non-conforming apps may be unable to be published (eg. FranceConnect or Belgium’s eID); will they be forced to implement Sign-In with Apple to get published in the AppStore?
To this day, no final date has been confirmed by Apple for application compliance and Sign In with Apple is in beta mode since the beginning of this summer.
A solution inspired by standards but with major differences
Apple’s social login solution is based on OpenID Connect.. OpenID foundation experts tested it as soon as it was available on the Apple Developer console and released a document detailing the differences between Sign-In with Apple and the OpenID Connect standard. Among the differences there’s:
- No use of PKCE which protects against authorization code compromise, especially for public clients (with no secret or no means to correctly protect their secret)
- No use of the nonce parameter in the IDTokens which can make the protocol vulnerable to CSRF attacks (edit: this has been recently updated by Apple)
Among its peculiarities, we can mention:
- Client secret being generated for each request in a signed JWT form
- No possibility to change the IDToken content, even through the use of the scope parameter
OpenID foundation published an open letter to Craig Federighi asking for updates to the protocol to make it OIDC compliant, asking even for certification against the specification and lastly asking for Apple to join the OpenID foundation. Apple did not officially answer this open letter yet, but inconsistencies spotted in the documentation were updated following it.
IAM market reaction
For now, very few have integrated this feature into their applications, mostly because the solution is very new and no-one has fully measured the impact of Apple’s approach.
That said, some Customer Identity and Access Management vendors are already working hard towards the solution: some plan to integrate Sign-In with Apple in their offering and some already have it available in beta with test identifiers to actually test the experience proposed by Apple.
On GitHub, vendors of on-prem solutions have patches allowing their users to implement the feature right now and several frameworks and language libraries have implementations of Sign-In with Apple clients: React Native, Node.js and Ruby.
The Sign in with Apple story is far from being at an end; we’re still waiting for Apple’s official answer to remarks from the OpenID foundation and more detailed information on the new AppStore policy. UntilApple makes it clearer, there’s a chance that the market will stay cautious towards this feature, yet it might be a good idea to prepare for application updates. Apple will probably be a major actor of social login from now on.
Henri Lefevre and Bertrand Carlie Wavestone
Identiverse® is IDPro’s ‘home’ event – an opportunity to get together with colleagues across the industry and to learn from each other as well as get updates on new standards, technologies, solutions and products, and to hear from visionaries both inside and outside the industry about things that might affect us in the longer term.
It would be impossible to do justice to everything that happened during the week in a summary format. In due course, the Identiverse team will be making videos available of the various presentations, and that’s probably the best way to catch up on the details. Here, then, we’ll try to provide an overview of some of the key themes that emerged during the week, at least from our perspective. We’ll undoubtedly miss some things you thought were particularly noteworthy, and we encourage you to highlight your own high points in continued conversation on Slack!
Innovation
After a few years of relative calm, it seems like the identity ecosystem is undergoing another period of rapid growth. Along with new product offerings from well-established vendors, we also saw a range of new vendors on the expo floor. Some of these are established vendors from adjacent sectors starting to make themselves more visible to the Identity sector – companies such as Feitian and Focal Point. Some were companies you wouldn’t immediately associate with the Identity industry – Capital One was perhaps the stand-out example. Identiverse also attracted an increased number of startups this year; this is a good trend to monitor since it gives some indication of the health of the overall market.
A number of sessions and keynote presentations also gave insight into new approaches to addressing identity challenges. We heard about emerging standards in areas including distributed identity, identity signalling, and access control. We saw developing success in implementation and real-world deployments of standards like FIDO and UMA. And there was plenty of healthy discussion of novel approaches to certain identity challenges based around distributed ledger technologies.
This was the first year that Identiverse has run a track dedicated to application developers – by all accounts this was a well-attended series of topics. This is an important audience to get on board in terms of embedding the use of modern identity protocols and standards such as OpenID Connect and OAuth; it was good to see those topics so well attended.
Privacy
The GDPR appears to have kick-started a much broader conversation about Privacy. Several of the keynote speakers noted that with companies like Apple now making Privacy a competitive differentiator, many organisations are rethinking their approach to the protection and use of customer data. There was also plenty of discussion around identity verification (and not only in the context of know-your-customer and anti-money laundering regulations) and the use of high assurance attributes.
Questions around the ‘ethical’ use of Identity look set to be a significant thread for the next few years at least. Several presentations touched on the delicate balance between security, privacy, and usefulness. There are implications for standards development, technology choices, and systems design – and although the questions are sometimes simple, the answers are rarely obvious. That means this is also going to become a boardroom topic… and there were a few professional skills presentations that touched on how to improve C-level communication skills
Several initiatives are underway to help companies make smart choices and sensitive investments in identity technologies – the Better Identity Coalition and Omidyar Network’s GoodID project both provided some insight here.
User Experience
Several of the keynote speakers observed that it’s hard to make lasting progress with improved identity – particularly with consumer- and/or citizen-focused identity – in the absence of real improvements in the user’s experience. This theme was picked up across a number of the tracks; in particular from a Consumer/Customer Identity Management perspective as well as in some of the government and healthcare topics.
It was gratifying to see the penetration the concept of “Zero Trust” has made in the industry; many of our sponsors on the expo floor were demonstrating how they can help us move the needle in this space. A number of vendors also announced new features in their products to continue the “passwordless” journey.
There was also a fair amount of discussion around how to ‘do’ identity in more challenging environments. Thin file KYC, identity for digitally disenfranchised communities, identity in the developing world where the technology landscape is fundamentally different… these are all important topics which will have an impact across the board.
Overall, it felt like we’re just getting started in this entire area, and there’s much more left to discuss: perhaps a significant area of focus for next year?
Other Announcements
Several companies and standards bodies made announcements during the week. We’re picking out here the ones that we particularly noticed – again, we’re sure there were others, so do chime in on Slack if there’s anything you think the community as a whole should be paying attention to. In no particular order:
- Coming off the back of tangible success with the FIDO 2 standards, The FIDO Alliance announced a significant expansion of its remit, adding industry working groups focused on identity verification and authentication for IoT devices – both of which support FIDO’s singular mission of eliminating industry dependence on passwords.
- Microsoft previewed support for FIDO 2 and WebAuthn in Azure Active Directory and Windows Hello
- Omidyar Network provided an update on their GoodID initiative
- And finally, your very own IDPro formally launched the Body of Knowledge contribution process, and announced several new corporate members, including AWS.
To round out an amazing week, IDPro ran its very own track on Friday morning. In line with our mission, these sessions focused on what it takes to become an Identity Practitioner, managing change within your organization, active listening when gathering requirements, and the evolution of identity over the decades. The track culminated in an engaging session on becoming an Identity Jedi Master! The entire track was well attended and very well received. In case you missed it, keep an eye on YouTube for the sessions to be posted in the weeks to come.
On top of all of that, there were hundreds of conversations in the corridors and over drinks throughout the Identiverse week, all helping to accelerate our industry. There’ll be a lot to catch up on at Identiverse 2020 in Denver!
IDPro Editorial Committee
The diversity issue in science, technology, engineering and mathematics, collectively known as STEM, is well documented.
In a report from Inclusive Boards[1] in the UK, women make up only 12.6% of board members in the sector – compared to the 30% female representation now achieved by FTSE 100 businesses.
In a study around gender diversity the UNESCO Institute for Statistics[2] examined the gap in science and found that worldwide, only 28% of science professionals are women. In Sub-Saharan Africa, only 30% of women are exploring in STEM and in the US in Silicon Valley 76% of technical jobs are held by men[3]
But gender diversity only represents part of the problem. In the UK just 8.5% of senior leaders in technology are from a minority background[4], and a report from the Ascend Group found that the racial gap in tech leadership positions between white men and minority men was larger than the gender gap between white men and white women.[5] White women were 31 percent more likely than Hispanic men to be executives, and 88 percent and 97 percent more likely than Asian and Black men respectively. Meanwhile, for minority women, the “race-to-gender factor” has only worsened since 2007. Reads the report: “In general, although minority women faced both racial and gender gaps … race, not gender, was increasingly the more important factor in limiting minority women in the pipeline.”
Bias
We all consistently apply our biases throughout daily life—in our hiring decisions, reviews, and in casual interactions. Even well-intentioned people can harbour unconscious biases that perpetuate stereotypes.
If everyone on your team looks the same and is from a similar background, you may reach consensus quicker about what to develop, build, or even the strategy for the company, but are those decisions the right ones?
What Are The Consequences?
We are now starting to see analysis of bias within technology systems, and some of those systems sit within and adjacent to the identity industry.
A study by MIT researcher Joy Buolamwini [6] found that some facial-analysis systems produced an error rate of 0.8 percent for light-skinned men; this error rate increased when a white female face was shown and ballooned to 34.7 percent for dark-skinned women.
( Joy Buolamwini, a researcher in the MIT Media Lab’s Civic Media group)
According to the paper, researchers at a major U.S. technology company claimed an accuracy rate of more than 97 percent for a face-recognition system they’d designed. But the data set used to assess its performance was more than 77 percent male and more than 83 percent white.
This kind of bias is going to make systems less inclusive, and ultimately less effective.
How Does Diversity Help?
A study by the Boston Consulting Group (BCG)[7] found that diversity increases the bottom line for companies. In both developing and developed economies, companies with above-average diversity on their leadership teams report a greater payoff from innovation and higher EBIT margins. The study found that “increasing the diversity of leadership teams leads to more and better innovation and improved financial performance.” Companies that have more diverse management teams have 19% higher revenue due to innovation.
Additionally, research by Mckinsey[8] Delivering through diversity, reaffirms the global relevance of the link between diversity—defined as a greater proportion of women and a more mixed ethnic and cultural composition in the leadership of large companies—and company financial performance, measuring not only profitability (in terms of earnings before interest and taxes, or EBIT) but also longer-term value creation (or economic profit), exploring diversity at different levels of the organization, considering a broader understanding of diversity (beyond gender and ethnicity), and providing insight into best practices.
These findings are huge for tech companies, start-ups, and industry where innovation is the key to growth. It shows that diversity is not just a metric to be strived for, it is actually an integral part of a successful revenue generating business.
There is also evidence that more diverse teams, make slower but better decisions. Jerry Kang, Vice Chancellor for Equity, Diversity, and Inclusion and Distinguished Professor of Law at the UCLA School of Law has stated: “Diversity will increase the universe of possibilities, solutions, and ideas considered. But it often creates a sort of friction, so it slows things down. It’s not always that it creates a different answer. But the way the answer is created, and the number of solutions are expanded—that’s what’s improved.”[9]
What Does This Mean For The Identity Industry?
When we think about this in the context of identity solutions, the need for diversity is arguably even more concentrated. Humanity is diverse, therefore identity solutions (which are being designed for humans) need to be able to embrace that level of diversity to work optimally.
As an industry, if we are developing standards, technologies and solutions for identity, we should be thinking about how we include those we are building them for on our teams, in our design, in our testing, and in our deployment. Digital identity solutions built for everyone should be built by everyone.
What Can the Industry Do
After 2 years of informal gatherings and discussions that helped scope the problems and the potential solutions, Women in Identity was formally established as a not-for-profit, grassroots organisation in June this year, with a mission to help inspire, elevate and support a more diverse workforce in the digital identity industry. The organisation is open to everyone and has long term ambitions not only to support individuals in their career development, but also to help employers and the industry as a whole develop better practices. These efforts, aided by other like-minded organisations and individuals, will in turn lead to products and solutions that are properly fit for all. Because diversity for our industry isn’t a desire…….it’s a necessity.
You can find additional information at www.womeninidentity.org
About the Author
Emma Lindley is an advisor on digital identity and co-founder of Women in Identity a not for profit organisation focused on developing talent and diversity in the identity industry.
Over a career of 16 years in identity Emma has held various roles, most recently as Head of Identity and Risk at Visa, previous board level roles at Confyrm, Innovate Identity and The Open Identity Exchange, and was instrumental in the commercial development of GB Group’s position in the identity market back in 2003.
She has been recognised in the KNOW Identity Top 100 leaders in Identity in 2017, 2018 and 2019, the Innovate Finance Powerlist for Women 2016 and 2017, and was voted CEO of the year at the KNOW Identity Awards. She has an MBA from Manchester Business School and completed her thesis in Competitive Strategy in the Identity Market.
[1] https://www.inclusiveboards.co.uk/tech-report-launch/
[2] http://uis.unesco.org/en/topic/women-science
[4] https://www.inclusiveboards.co.uk/tech-report-launch/
[6] http://news.mit.edu/2018/study-finds-gender-skin-type-bias-artificial-intelligence-systems-0212
[7] https://www.bcg.com/en-us/publications/2018/how-diverse-leadership-teams-boost-innovation.aspx[8] https://www.mckinsey.com/business-functions/organization/our-insights/delivering-through-diversity
[9] https://www.ericsson.com/en/blog/2019/3/how-can-we-stop-technology-from-inheriting-our-bias
“I can’t do authorisation – it’s way too close to the business.” This quote, ventured by a colleague, exemplifies both the opportunity and challenge of providing authorisation services in an enterprise context. Anyone taking on this space can expect to gather insights into business processes at a breadth and depth few enterprise services afford. At the same time, reluctance from both developers and product owners will require a level of salesmanship few of us are used to. Why is that?
Don’t touch my authorisation
Two key factors appear to give application teams pause when asked to let another team take care of the decision of who can do what within their application. First, authorisation immediately impacts the user flow. In an ideal world, nearly all of the user interface will be driven by the level of access users have been granted. After all, no one likes a pop-up saying “access denied”. For most users, ignorance as to what they don’t have access to is bliss. For an application rich in features and data this means many round-trips to the authorisation service until the canvas is populated.
Second, quite a few application-level authorisation services appear to have grown out of what was fundamentally a data management challenge. Take for example the contract management system for corporate payment services. The contracts are highly structured and, among other data points, contain payment limits, four-eyes requirements for specific payment types, etc. Initially, the system captured this information to generate contracts. These days, the same system exposes part of the contract as authorisation information for payment-related applications. Asking the product owner to access this contract data from an enterprise authorisation solution is bound to make them nervous. Many others feel the same.
From the perspective of someone running an enterprise-wide programme, this reluctance to engage creates challenges. Responsibilities to manage the line of business-specific authorisation information, and structure rarely map neatly to enterprise-level responsibilities. This complicates business-as-usual processes. And while authentication, request and approval, or governance are lower-order systems integration challenges, ex-post integration of application-level authorisation requires a level of effort that threatens the overall business case.
For the record, a centralised authorisation service provides many benefits for the organisation. Greater consistency, ease of integration with the remainder of the identity and access management solutions, single point of implementation for corporate policies being a few worth noting. Enterprise authorisation, thus, approximates a key challenge familiar to any economist: Rational decisions at the application level lead to sub-optimal outcomes at the enterprise level.
Try, fail, rinse, repeat
Trying to wrestle this to the ground led to the E-TERRA approach. Through a series of conversations it became clear that the single-application authorisation solution, while far from dead, was not the norm. Instead, applications supporting the same business process appeared to have clustered around a limited number of authorisation solutions. Their owners, in turn, wrestled with the increased complexity as well as the user experience when it came to actually getting access. Building on this, the approach was structured as follows.
Explore: The first step is to survey the landscape and build an understanding of the specifics of the most successful services. It also helps owners to realise that others are wrestling with the same challenges.
Target: This phase essentially answers the question “What does good look like?” The box highlights a few implementation details good authorisation services seem to share.
Educate: While they feel a sense of ownership, developers rarely burn for authorisation. Helping them understand the specifics of a solution and how to integrate goes a long way. Sequence diagrams, API documentation, and configuration information for their favourite hosting environment appear to be good starting points. Make them available in a central location.
Reference: Functional access is usually highly specific to the application. Data access (as highlighted above) is frequently shared across a business process. Integrating the relevant data sources into the authorisation service as reference data is key to success.
Rationalise: Now is the time to start joining forces across authorisation services to reduce duplication and focus efforts. This phase should not be contentious as at this stage, owners of the authorisation services will have worked together for a while and built a measure of trust.
Administer: A solid business-as-usual process bookends the approach. It is important, however, to note that this will need to accommodate business administrators to ensure the authorisation service can deal with the complexity and speed of today’s enterprises.
Success – now what?
If (and it’s a big if) the E-TERRA approach succeeds, the time will come that one solution will be declared legacy in favour of a more strategic one. Incidentally, sometimes this happens even in the absence of a structured approach, be it due to key team members moving on, budget pressures, or whatever else, leading to a rethink of strategic priorities. This is the time of transition and migration – which has its own set of challenges.
More successful solutions will have achieved a degree of integration with the remainder of the platform, whether it is authentication, request and approval, or provisioning. Application teams will take this for granted. Key success factors for a transition project are:
- a full understanding of the scope of the legacy solution and their integration points with the platform (such as authentication or provisioning);
- an internal transition management that coordinates the migration of identified integration points;
- leveraging the existing configuration to drive on-boarding (eg. request and approval) instead of starting from scratch; and
- being prepared for internal and external road-blocks such as budget challenges.
Finally, it pays to understand key stakeholder concerns which tend to focus on lead-time to allow for proper planning and the benefits to be achieved.
In closing, it stands to reason that authorisation is one of the most exciting spaces to be in as it provides for a rich blend of technical and business challenges. To quote another colleague “So now we are talking political architecture?”
Olaf Greweis the Head of Authorisation Solutions at Deutsche Bank and a founding individual member of IDPro.
During the third week of May Identerati from all over the world converged upon Munich for the 13th KuppingerCole European Identity & Cloud Conference. IDPro membership was well-represented, and not just among attendees; sessions, panels, and keynotes were delivered by (deep breath) David Brossard, Bertrand Carlier, Pamela Dingle, George Fletcher, Allan Foster, Gerry Gebel, Steve Giovannetti, Ian Glazer, Andi Hindle, Andrew Hughes, Steve Hutchinson, Mike Jones, Nishant Kaushik, Mike Kiser, André Koot, Martin Kuppinger, David Lee, Jon Lehtinen, Jean-François Lombardo, Eve Maler, Andrew Nash, Lance Peterman, Mike Schwartz, Fady Semaan, and Colin Wallis. With so many IDPro members in Germany, a meetup at Augustiner-Keller was just the thing to make sure everyone got their week started off right with plenty of beer, pork, and pretzels.
While participants adjusted to the time zone differences, all of Monday and Tuesday morning were occupied by meetings and workshops presented by standards and initiatives bodies, including the FIDO Alliance, the Kantara Initiative, the OpenID Foundation, and various blockchain-centric and self-sovereign identity efforts under the Blockchain ID Workshop. The FIDO Authentication Workshop reviewed the technical concepts behind FIDO authentication, implementation roadmaps from vendors, and dove into implementation case studies and lessons learned. The Kantara Initiative presented a demo of its Consent Receipt specification, as well as provided updates on its other programs like UMA2 and Identity Assurance. The OpenID Foundation Workshop gave updates on its current standards efforts (including MODRNA and FAPI), a report on the award-winning Self-Certification Program, and detailed view into OpenID Connect for Identity Assurance. The Blockchain ID Workshop was less a report on the status of any one organization’s initiative and more a coalition of decentralized identity players presenting on their use cases and implementation of blockchain-based identity, particularly within an enterprise context. Microsoft, Sovrin, Evernym, Consensys, and IBM presented.
The conference began in earnest Tuesday afternoon, and the keynotes clearly set the themes for the week: privacy/regulation, self-sovereign/blockchain identity, artificial intelligence/automation, and enterprise/customer identity best practices. Whereas many of the keynotes stuck well within the technical/regulatory lanes of identity and privacy, there was some surprisingly philosophical content among them as well. One which merits special mention in the view of the author is Dr. Emilio Mordini’s “Das Sterben der Pythia” – On Humans, Artificial Intelligence and Oracles (requires login) because identity (as generally practiced within IDPro) is necessarily married to technology, and as such finds itself susceptible to the same tendency to venerate technology as the final arbiter of the possible (and where something is not currently possible, it is assumed that advances in technology will make it so someday) at the hazard of ignoring the human elements and solutions of the problem and practice in the interim.
Throughout Wednesday and Thursday, there were tracks on Microservices, Identity Standards and Architectures, Enterprise Identity, Customer Identity, Privacy by Design, Machine Learning, and Blockchain Identity. Despite the wide track list (over 20 tracks), a few topics were visibly woven throughout a large portion of the content. First, that dynamic services and processes are taking over from fixed processes. Whereas organizations may have a fixed authentication and authorization service or policy, consensus from presenters was that this is no longer enough. Consider authentication. Distinct from “continuous authentication,” which assumes a constant, chatty channel over which to continuously authenticate a principal, a dynamic authentication service should consider the authentication context of a transaction, based on signals such as time of day, location, device information, etc., and decide to apply authentication only when the authentication context changes. This gets difficult very fast as one must decide what the “normal” context is, which is where these sessions would often leap into the machine learning/AI topics.
Second, identity verification and proofing are getting recognized as critical for the enterprise to adopt as a necessary component of a holistic information security strategy. The urgency behind the adoption of identity verification and proofing is similar to that of adoption of multifactor authentication a few years ago. Identity verification and proofing are processes by which a person validates their identity, often using external sources of assurance, like public records, credit bureau information, or government-issued documents, for certain business processes such as account recovery. For years there has been talk of addressing the data provenance question of identity; organizations tend to trust information because it came from within the organization. Identity proofing rectifies a type of provenance question when someone cannot verify themselves using recognized credentials.
Finally, decentralized identity continues its push for adoption, regardless of the barriers to enterprise or customer adoption. Microsoft had several representatives at the conference, and they presented a unified theme of users needing to be put in control of their own data, and self-sovereign identity being the tool that would enable this. Though there were some sticking points (e.g. one keynote suggested consumers could become their own Data Controllers, a role which has a very specific definition under GDPR), they demonstrated their commitment by announcing the launch of the Identity Overlay Network, or ION. Elsewhere, demonstrations and case studies on the practical implications of using decentralized identifiers could be seen. There was no shortage of passion and effort behind decentralized identity, though the author still has not seen a good answer on getting past the usability hurdles of wallet management in a world where grandpa still operates a feature phone.
For those who could not attend EIC this year, the good news is that many of these same topics will undoubtedly emerge again at this year’s Identiverse conference in Washington D.C. Visit the Agenda page to see which speakers and sessions will be diving into and expanding upon these themes at Identiverse.
Jon Lehtinen
IDPro Editorial & Body of Knowledge Committees Members
Nobody likes passwords. Users don’t like passwords because they are hard to remember and every system seems to have a unique password policy. Companies do not like passwords because they drive up support costs and reduce productivity. IT security does not like passwords because they are easily compromised. The news is filled with stories about stolen credentials, mega breaches, and reputation damage. Yet passwords remain. For years, new techniques for replacing passwords have come and gone with different levels of success.
Now there is a new standard that has a real chance to replace passwords. I know some of you are thinking that you have heard this before. A shiny new approach, but will it really work? Will it work in the real world? Will users actually adopt the new technology? Can it be implemented without requiring a massive project, expensive new infrastructure, and/or an army of consultants? This article will walk through the basics of WebAuthn and FIDO2 and how its ease of use, strong security, and industry support will accelerate the implementation of passwordless authentication and reduce the difficulty of use.
Background
WebAuthn is a W3C specification, ratified in March of this year, that evolved out of the FIDO Alliance’s Universal Second Factor (U2F) standard. It paves the way for common deployments across browsers, operating systems and applications.
If you have heard of WebAuthn, you have probably also heard of FIDO2. FIDO2 is a term that encapsulates the WebAuthn standard and the FIDO Alliance’s Client to Authenticator Protocol version 2 (CTAP2). WebAuthn and CTAP2 work in concert to eliminate passwords.
These standards work together and establish a method for asymmetric (public-key) cryptography and origin-bound key validation to verify the authenticity of the user to the relying party. The standards also provide protection against phishing attacks as only the relying party that initially performed the registration with the FIDO-compatible security key will receive a valid response. Each registered application has its own unique public / private key pair providing an additional level of security and privacy.
WebAuthn requests that a credential be created by the authenticator for a particular RP. The authenticator provides key management and cryptographic signatures. The authenticator generates the credentials. This eliminates the need for a company to implement and manage a public key infrastructure (PKI) for end-user authentication. This streamlined approach will make implementations and adoption easier for companies. The authenticator also provides an attestation certificate that provides basic information about the authenticator that the relying party can use accordingly. Attestation proves to the relying party that the keys generated originate from a genuine device.
WebAuthn and CTAP2 take the U2F authentication model and extend it for primary login as opposed to only enabling a second factor. The specifications include user verification (biometric and/or PIN) for added security. User verification (UV) provides a multi-factor authentication and ensures if someone gets ahold of the authenticator they cannot use it without PIN or biometric information. The PIN and biometric information never leaves the authenticator, and they serve only to unlock the authenticator for use. WebAuthn can be used as a second factor and is backwards compatible with U2F-based authenticators. Users have become accustomed to logging in using fingerprint readers and PINS so this form of interaction should be readily accepted.The specification also includes the concept of user presence (UP) which requires the user to perform an action, like touching a security key, to ensure a person is involved in the event.
Putting it all together
Strong, modern authentication requires a number of systems to work together. One of the challenges with mass adoption of U2F was that not all browsers support it. That brought the FIDO Alliance and the W3C together to work on standard ways to ensure implementations work across browsers and platforms. Now, all major browsers are actively working to implement support for WebAuthn and have some form of FIDO2 functionality working today with full functionality and browser parity coming in the not-too-distant future. Having WebAuthn and CTAP2 built into browsers and platforms reduces the need to deploy client software, making implementation much easier for services, relying parties, organizations and companies.
In order to integrate WebAuthn with their applications, relying parties will need a lightweight WebAuthn server. WebAuthn capabilities are being built into Identity Provider solutions or companies can build their own using open source projects. One such project can be found at https://github.com/Yubico/java-webauthn-server
Relying parties should plan for account holders to have multiple authenticators registered. Each public-private key pair is bound to an authenticator and cannot be copied or shared by design. Since multiple security keys can be tied to an account, a relying party should allow users to name authenticators for easier tracking and management. Authenticators come in a number of form factors that provide convenient options for users to authenticate. They can be built into the computer (Windows 10 provides this capability now), into a mobile phone (Android 7+ phones can be used for FIDO 2FA at this time), or be on a keychain like the YubiKey (FIDO2 ready) . The FIDO Alliance maintains a list of authenticators that are U2F and FIDO2 certified at https://fidoalliance.org/certification/fido-certified-products/
Traditionally, a password is used for the initial authentication since it is not bound to the device. To remove passwords, the initial login scenario needs to be resolved. One way to resolve this is to use security keys to help bootstrap new devices and support a passwordless option for initial login to an RP. A new device that can be used as a FIDO2 authenticator cannot be used until it is registered with the RP. A security key that is already registered to the RP can be used to perform the initial login. After initial login, the new device can then be registered and be used as a FIDO2 authenticator.
With the confluence of secure hardware at the user’s fingertips (in the form of security keys and secure elements within devices), WebAuthn ratification, and industry adoption, there is a viable solution to replace and or dramatically reduce the use of passwords. WebAuthn will attract users with its strong security, convenience, and ease of use. Even though the user will authenticate with different authenticator form factors, with unique credentials, the process will appear seamless. The work is not done but users can count on fully viable solutions very soon.
What now?
As an identity professional, what can I do to prepare for a WebAuthn deployment? Within your company, there are a number of things that can be done to prepare for leveraging FIDO2.
Review and update policies and procedures
We have been living with passwords for a long time and have built processes with that model in mind. Processes need to be revisited if passwords are not used or significantly reduced. How will onboarding be affected? How should recovery processes be altered? What type of authenticators make sense for the company? PINs are not considered passwords and should have their own policy.
Additionally, passwords have a one-to-one relationship with an account. With FIDO2, an account can have many credentials across different devices. This subtle shift can have some dramatic impacts to a company. As an example, access policies could be written based on which authenticator or authenticator family type is being used.
Work with your IDPs and RPs to support the standard
WebAuthn is gaining a lot of traction but unless the majority of identity providers and web applications implement the technology, it will take a long time to eliminate passwords. Vendors really listen to their customers to prioritize feature requests. The more they hear from IDPros, the sooner WebAuthn will be implemented into their authentication flows.
Upgrade to the latest browsers and platforms
Though the infrastructure footprint can be minimal, the technology is highly reliant on the latest browsers and platforms. Work with your counterparts within your company to ensure that browsers and platforms are being updated.
Start planning for a pilot
WebAuthn/FIDO2 can be used today with certain websites and more will be coming online soon. A pilot will help work through all the processes that need to be updated for a successful deployment.
Going Deeper
This article provides a high level overview of WebAuthn/FIDO2 but there are a number of details that can be explored in more detail, especially if you plan to implement WebAuthn for your own services.
If you will be attending the Identiverse conference in June, go to one of the many WebAuthn/FIDO sessions. Here is a short list of relevant sessions (details and additional sessions can be found online)
Tuesday, June 25th
- Google Masterclass: Democratizing phishing-resistant FIDO technology
- SecureAuth Masterclass: What passwordless technology can learn from American Prohibition
- Federating FIDO through a Blockchain
Wednesday, June 26th
- Ping Identity Masterclass: Implementing Passwordless Authentication with FIDO-based, Intelligent MFA
- The state of FIDO
- Netflix’s Journey with WebAuthn
Thursday, June 27th
- Standards: The Bedrock of Identity
- The next wave of Identity standards
- Ping Identity Presents: The Intelligent Future of Multi-factor Authentication
- Envisioning Authentication Beyond FIDO
Friday, June 28th
- SecureAuth Masterclass: What passwordless technology can learn from American Prohibition
- MFA for Real – reports from the field
Additionally here is a list of great resources to learn more about Webauthn and FIDO2 as well as public announcements of support:
- https://www.w3.org/TR/webauthn/
- https://fidoalliance.org/fido2/
- https://developers.yubico.com/FIDO2/
- https://webauthn.guide/
- https://caniuse.com/#search=webauthn
- Follow the IDPro fido slack channel
- Google Android 7+ Phone Is Now a FIDO2 Security Key
- Microsoft Achieves FIDO2 Certification for Windows Hello
David Treece is a senior solutions architect at Yubico and an individual member of IDPro.
Cast of Characters
(In Order of Appearance)
Narrator/Inquisitor: George Dobbs
Rey: Marc Boorshtein
Kylo Ren: Mike Kiser
Yoda*: James Dodds
Lando Calrissian: Jonathan Sander
Luke Skywalker: Jeff Lombardo
Finn/Poe Dameron/BB-8/Unnamed Bot: Matt Topper
*Character not appearing in this film
Thematic visuals for “research purposes”: https://www.youtube.com/watch?v=adzYW5DZoWs
Open to a black background, devoid of light or substance. The sound of heavy breathing, as if someone had just run a marathon after only training for a local 5K race. Proprietary logo reveals itself in an expensive Adobe after effect (may be out of current budget for this project.)
George / Narrator speaks slowly, with a rich, auto-tuned voice. Think James Earl Jones, but significantly more majestic.
George Dobbs / Narrator: What kind of entity is a robot? Large enterprises seem to be on a phase of adopting “Robotic Process Automation”. This adds a layer to existing application sets by having a “robot” pretend to be a human that has access to the set of applications. The robot is a form of script that does a well-defined business process repeatedly. Unlike other types of integration this requires accounts that look a lot like human accounts, but are run automatically. Recently my company has decided that these should not be treated like humans – as in there should be no HR record. This leads me to IDPro to ask this group – are there “best practices”? My immediate concern is around the creation of the record for the instance of the robot, so we can send it to the credential system, to get the access rights started. If not done in the HR system, where are others seeing this handled?
Fade up to a breathless Marc / Rey, scanning desert planet. It’s not Tatooine, at least according to J.J. Abrams.
Jeff Lombardo / Luke Skywalker: (Mysteriously and emphatically, just like you would expect a force ghost to speak; almost as if you had interrupted a vaguely important phone call.) We’ve passed on all we know. A thousand generations live in you now. But this is your fight.
Fade to black. White text fades in:
EVERY GENERATION HAS A LEGEND
. . .then fades rapidly back to black.
In the distance, a glowing speck on the horizon shimmers in the desert heat. You know it’s some kind of craft because you’ve seen this kind of movie before.
Marc Boorshtein / Rey: (Quietly, but firmly) Why not treat them as service accounts?
Jump cut to interior of the approaching ship. Camera focuses in on the gloved hands steering. No face, no other identifying marks, just rich, Corinthian leather promoting grip and control of the craft. A voice, presumably of the pilot, echoes metallically in the cockpit.
Mike Kiser / Kylo Ren: (Angry, but subdued) You could, I suppose, but I generally advocate treating them like contractors which means no HR, no benefits, but you DO need an authoritative repo for them. Then you can limit / track them like you would a contractor. (keep in mind that a contractor repo would be separate from this as well). There are a couple of reasons for this:
1) they are replacing contractors, or potentially are
2) they have some level of intrinsic access, which may involve access across apps
3) contractor model reminds of the need to make everything time limited: entitlement, life cycle, carts, etc. You lose some of that tracking etc. with pure account model.
James Dodds / Yoda: (Sagelly jumbling grammar): Recognize bots as new identity type you will, because it is important to differentiate bots from the rest of the worker population; bots do not need compliance training, to enter timesheets, get paid or have access to benefit plans. Have data consumers opt-in to bot data only if needed.
Marc Boorshtein / Rey: (Emotionally fragile, but firm) Not sure I agree. Assuming you have a process for creating and tracking service accounts you will need the same thing in this instance. Then the account’s ownership can be delegated to someone responsible. Someone will need to be responsible for the “robot”. And if you don’t have a process for managing service accounts then this would be a good time to create one.
James Dodds / Yoda: Always two there are, no more, no less. A master and an apprentice. Both service and bot are nonhuman – difference is the privilege of the bot
Mike Kiser / Kylo Ren: (Angrily) Completely agree with oversight. I do think that the model needs room to expand beyond a simple account, though, to express the agency that bots / RPA have. Also agree with needing a solid service account approach as well I think the contractor model also can encourage that oversight – by placing it more appropriately within the org. With service accounts, for instance, there is always a danger of dumping them all under one overseer. That issue still exists with bots as contractors as well, of course ….
James Dodds / Yoda: Adventure. Excitement. A bot craves not these things, yet must access many things. Service and bot are nonhuman at core and may share the same birth.
Marc Boorshtein / Rey: I think we are saying mostly the same thing. It’s more about the process then the tech.
Marc spins rapidly, igniting his pale blue lightsaber, and crouches as he stares down the insanely rapid approach of the TIE Silencer.
Mike Kiser / Kylo Ren: (Rapidly and angrily) Agreed – I’m open to discussion. Another neglected side of bots is discovery in the first place – lots of innovation / independent adoption going on without notification of the identity program.
Marc / Rey breaks into a sprint as Mike / Kylo Ren overtakes him, certain to obliterate him as only a large metal object moving at ludicrous speed on a desert planet can.
Fade to black. White text fades in:
THIS CHRISTMAS
. . .then fades rapidly back to black.
[Note that this scene is not seasonally dependent.]
Marc Boorshtein / Rey: I think ultimately a service account should be treated like a regular account with one exception. There’s someone or a group responsible and accountable. Your robot needs access to an API? The responsible person requests access to that API on the service account’s behalf. Well, I think lack of integration of Enterprise identity has much more to do with the difficulty of getting resources and agility out of most Enterprise identity teams.
Marc leaps, unnecessarily, off of his back foot, and spins into the air. With apologies to Douglas Adams, he hangs in empty space much in the same way that bricks don’t. He is now at about eye level with the pilot, and enters the expected slow motion to make sure that the producers get the maximum value out of their special effects team.
Mike Kiser / Kylo Ren: (Angrily surprised) I would mean to use PAM for service accounts and then have the bots go through PAM process to get access as needed.
Marc Boorshtein / Rey: Potentially. Not sure I’d want to go through a PAM process for everything a bot may need. But I’m sure some things deserve that level of scrutiny.
James Dodds / Yoda: When you look at the bot side, careful you must be. For the bot side looks back. Controls apply to the privilege granted, not the type of account.
Mike Kiser / Kylo Ren: (Accelerating angrily) Likely depends on the use case, as always. Guidelines are suggestions until you actually understand the circumstance.
Marc, blatantly continuing to deny the reality of gravity on this arid planet (but to be fair, we’re not really given its mass, so maybe it is completely realistic), continues his rapid rise. He is now upside down, facing the oncoming transparent cockpit, ready to use his weapon which historically would not be useful for high-velocity combat.
Marc Boorshtein / Rey: Agreed
Cut to black. Fade up on a mysterious dark planet. It is night, clouds mysteriously obscure much of the view. Lights twinkle in an opulent landscape, which beckons to the viewer but is shrouded in mystery. What is potentially an A-Wing zooms past cliffs and jagged peaks and descends towards the city. Mysteriously.
Narrator (George Dobbs) still speaks slowly, with a rich, auto-tuned voice. He’s left the James Earl Jones vibe behind, and is rapidly approaching what can only be described as “Morgan Freeman in a Nature Documentary.”
George Dobbs / Narrator: Thanks for the discussion. A little more background. Today it is handled like contractors. Contractors are passed into the HR system so they get treated like EE’s (mostly) for things like org charts and access control. One odd thing is that the robots now end up in the org charts. Ha! My initial concerns are extending SoD to the robot “owners” and managing the owners as they come and go.
James Dodds / Yoda: Simple classification will keep the bots in their place. So certain were you. Go back and closer you must look.
George Dobbs / Narrator: One thing that is different with these accounts is they have to handle the password rotation exercises and somehow fudge any MFA setup. The ideal solution would not allow the robot operators to inspect the credentials.
George Dobbs / Narrator: So, my sense is similar to service accounts but not identical.
Marc Boorshtein / Rey: Yes. Thing is, you need to have the management of account owners regardless (at least until the machines take over and then the management issue is solved).
George Dobbs / Narrator: Right, then we just flip it on its side and the machines manage us!
Marc Boorshtein / Rey: Agree on the human owner not knowing the creds. Whether it’s something like Vault/Conjur or Spire some kind of short-lived one-use token is needed for robots. That way you manage the risk of it becoming a vulnerability. Ah, what bliss that will be! Although knowing my luck I’ll be stuck in meetings with cyborg executive officers explaining for the 10 millionth time that storing a password as clear text in a database table is a terrible idea.
Jump cut (again) to Jonathan / Lando sitting beside Chewbacca in the Millennium Falcon. They jump to lightspeed as Jonathan / Lando laughs, handsomely.
Jonathan Sander / Lando Calrissian: (Cachinnating confidently, without a care in the world but certainly not without a thesaurus) Many of our customers have “bots” and “service accounts” (both ill-defined terms/concepts in my mind), and the strategies to manage them vary to a degree almost equal to the number of them I’ve spoken to about it. One thing they all have in common, though, is the agreement that the biggest difference between service accounts and bot accounts is that service accounts do things on behalf of a thing and bots do things on behalf of a person. That specific idea does often clarify which roads they ought to go down in whatever internal processes they may already have. My bots do things for me. The department’s service accounts do things the department needs to have done. The latter is diffuse accountability and responsibility while the former is very specific. And this typically implies a great deal of delegation discussion – which for us has driven all the requirements for our OAuth 2.0 rollout.
George Dobbs / Narrator: If HR dept. owns records for employee-humans, and Procurement dept. owns records for contractor-humans, who owns records for so-called robots?
James Dodds / Yoda: Difficult to see. Always in motion is the future nonhuman id. Judge me by my size, do you? <Kick into the air>
Jeff Lombardo / Luke Skywalker: (Speaking from everywhere and nowhere at the same time) Ops? DevSecOps (for what that means)? RPA is just the grand-child of Automated Testing being used for more than just fuzzing the UI with random data. Now we are fuzzing intelligible and legit data as part of a workflow, event, scheduled tasks.
Cut to Finn and Poe as they stare out from a rock outcropping. Poe stands behind Finn from an elevated position. The framing for the shot is perfect, as if they are about to release their first studio album together as the world’s smallest boy band.
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Finn) I’m still struggling with why bots aren’t treated like service accounts. If service accounts are doing things on behalf of an application that application still has an owner responsible for the access. I don’t see how a bot account is any different. In most cases these bots are recorded, fed data and executed on a centralized server not locally on each person’s machine
Rapid fade to shot of Matt (BB-8) and also Matt (“Unnamed Bot.”) Both droids (bots) are completely unaware that the entire movie has centered around how to govern them appropriately.
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: As BB-8 and Unnamed Bot, slowly cock heads to one side) . . .
Cut to Marc/Rey, staring across a tempestuous sea, with the remains of what looks to be a death star on the horizon.
Jeff Lombardo / Luke Skywalker: (Larger now, as if he has stepped into a large, empty public theater before the Hamilton rehearsal starts) Employees are processed from HR because they are paid and we know they will stop being paid as soon as necessary. So, we delegated the risk to people who actually care. We also do that because we need to reflect on promotion (demotion), and lateral movement in the organization. Again, we delegate our burden on entitlements to those same people who care(and sometimes their managers). Same applies to contractors, but because it is contractually bound (payments and scopes). Here’s why scope changes with contractors. Robots are not paid (no salary nor bill) and are not promoted (and co) in the sense of accessing corporate benefits and obligations (week end calls, etc.). So before creating new workflows, what does the service accounts process not support in a robot lifecycle? If anything, isn’t improving the service account workflow easier than reinventing something?
Marc Boorshtein / Rey: Yes. I think that if you fix your service account management it would likely cover robots. Most orgs have paper-based service account management (if that).
James Dodds / Yoda: They are both nonhuman accounts, young padawan. Just different classes with different paths.
Quick shot of Mike’s / Kylo’s mask being repaired (presumably from the damage previously caused by Marc / Rey with the up-close-and-personal Jackie-Chan-style lightsaber leap.
Mike Kiser / Kylo Ren: (Somewhat less angrily) What does it look like if the use case spans applications? I’ve seen orgs with a bot that accesses lots of different apps all in one workflow. Isn’t using service account governance segmenting that artificially?
Marc Boorshtein / Rey: Only if you assume that service accounts are scoped to a specific application.
Instant shift to a red filter. Mike / Kylo is carving a path through opponents with his patent-pending lightsaber. There appear to be storm troopers in the background, but the entire focus should be on Mike / Kylo and the hyper-intense crimson saturation which has now blown out our visual cortex.
Mike Kiser / Kylo Ren: (Violently angry, throwing whoever or whatever happens to be nearby) Per Matt, he was stating that they were. Does that mean that the service account is in a central repo? Has to be somewhere, I suppose.
Marc Boorshtein / Rey: I don’t see why they need to be. The only difference between a service account and a user account at a technical level is bits-and-bytes. If AD is your central repository you can store a service account there. If your app doesn’t use a central repo then you have similar issues as user accounts from a data/technical perspective
James Dodds / Yoda: If central repository was non-human account “owner aware,” what a blessing when the death star takes away owner…
Marc Boorshtein / Rey: if you break it down into three layers:
1. Governance
2. Data
3. Integration
#3 doesn’t really change between a service account and a user (maybe a few specific use cases like MFA) and is very application specific.
Rapid horizontal wipe to Matt (Finn) and Matt (Poe) in the middle of a vicious fight onboard a . . . whatever that thing is. He (they?) are definitely being chased by storm troopers on speeder bikes, though. The chase is frenetic, with rapid West-Wing-style dialogue and quick cuts back to Marc / Rey (not present in the battle, but is in a remote location with a great high-speed connection for the impromptu discussion.)
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Finn) You can either scope them to the application owners that the bots are calling, or the business unit owners/managers for the department they are fulfilling the actions for. I’ve seen service accounts tied to either model. The latter seems to work better because it gives them incentives to actually care when the passwords need to the rotated
Marc Boorshtein / Rey: #2 you need some data/metadata about the account to identify it as a service account and link it to an owner. #1 is where the fun really happens with service accounts
Mike Kiser / Kylo Ren: (Still angry, but out of breath, so is forced to calm down a bit) Agreed on tying to dept. Do service accounts have a lifecycle? Do they get spun up and spun down?
Marc Boorshtein / Rey: In theory, yes. They have all the same compliance issues any other account does.
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Poe) Yes, and their access must be governed and reviewed too.
Jeff Lombardo / Luke Skywalker: +1 there. And in any case it is no different for a service account than for robot account.
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Finn) Heck, most robots/services have 2 identities in the system because they can’t afford the downtime to rotate the passwords in a coordinated attack so they’re given a “new” or second account with the new password when it’s time to rotate. (Did I mention how much I hate enterprise software?
Jeff Lombardo / Luke Skywalker: Credential vaulting for scripts (A2A) can now support many schemes so it won’t be a problem to adjust that to robot callers.
Marc Boorshtein / Rey: Assuming your app knows how to use it.
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Poe) Agreed, assuming the software was smart enough to use the vault
Marc Boorshtein / Rey: And there are no standards there. Closest thing you can say is something like secrets in K8S.
Jeff Lombardo / Luke Skywalker: Standards are up to us, but I agree the legacy market has to be dealt with. I was focusing more on the scripting market.
Marc Boorshtein / Rey: Disagree, standards are up to the folks using it (at least from a de facto standpoint).
Mike Kiser / Kylo Ren: (Angrily demanding answers) Can service accounts use PAM?
Marc Boorshtein / Rey: Why not?
Jeff Lombardo / Luke Skywalker: Are we only philosophers in IDPro? I thought we were also the ones using it.
Marc Boorshtein / Rey: If an identity exists in a store, but no application can use it, does it exist?
Jeff Lombardo / Luke Skywalker: Marc, I would say: define “cannot use.” it is still a dormant/orphan account at least. It was at least tied to a purpose in the past so it is never stripped of its Identity. But we diverge from the standards of vaulting.
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As BB-8 and Unnamed Bot) I’d love to see the RPA market give users a way to “delegate” permissions from users to the RPA platform and have them store the tokens and use them on behalf of the user #UMA then when we kill the user, we also kill their OBO tokens.
Marc Boorshtein / Rey: RPA?
Mike Kiser / Kylo Ren: (Didactically angry) The narrator already told you! Robotic Process Automation!
Jeff Lombardo / Luke Skywalker: That’s the new term. Old made new.
Mike Kiser / Kylo Ren: (Resigned, but still angry) I think a ton of people are using Blue Prism, etc. and so want to govern them from a bot perspective rather than a service account model.
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Poe and Finn at the same time, with the same intonation and rhythm) Aren’t they all Digital Transformation = Web 3.0 because we already used Web 2.0 and it doesn’t sound as cool? We’re heading right back to mainframes that just don’t live on site anymore.
Fade to a two-pronged sequence. First is a medal (similar to the one from the end of “A New Hope”) held by immaculately manicured hands. Then fade into a close up of Marc/Rey embracing Leia. Next two lines are voice-overs.
Mike Kiser / Kylo Ren: (Oddly upbeat) I feel like service accounts is a good area to account for, but I think that we’ll have to account for bots as an identity type rather quickly. The assumption may be scripting at this point, but I think that long term there will be agency involved. At that point, I think we’ve moved beyond a simple account.
Marc Boorshtein / Rey: it’s all just data.
James Dodds / Yoda: The bots are all over the enterprise. If not accounted for by now, already behind we are! In a dark place we find ourselves, and a little more knowledge lights our way.
Jump cut (again) to Jonathan / Lando sitting beside Chewbacca in the Millennium Falcon. They jump to light speed as Lando laughs, handsomely. Note: this is very similar to Lando’s other scene, but this time they come from the opposite direction. Wherever they’ve gone, they’re clearly returning joyfully.
Jonathan Sander / Lando Calrissian: (Chuckling to himself) Some of this strikes me as a difference in business model needs. bots that span apps are likely associated with business roles (people or other) that would need to do that for business reasons. In a mesh org where humans cross those lines it only makes sense that bots & service accounts may do as well.
George Dobbs / Narrator: If HR dept. owns records for employee-humans, and Procurement dept. owns records for contractor-humans, who owns records for so-called robots?
James Dodds / Yoda: I do. I mean I AM, am I?
Back to Marc/Rey, still staring across a tempestuous sea, still with the remains of what looks to be a death star on the horizon, but now with all of the key players. (Except for Mike/Kylo, because that would either be socially awkward or a massive spoiler. Or both.)
George Dobbs / Narrator: For a more amusing question. What is the collective plural for robots? A herd, pack, gaggle, murder, parliament?
Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: I like Swarm, makes people feel like the drones are coming.
Jeff Lombardo / Luke Skywalker: (Summing up all that he said before to drive home the point, with music building to a crescendo) Bots will always be with you. No one’s ever really gone.
Fade slowly to back, with a haunting, digitized laugh echoing throughout the landscape.
Fade to black. White text fades in (embedded in the IDPro logo, if we had one):
THE RISE OF BOTS
. . .then fades rapidly back to black.
Back in the mists of time, when I was taking my first steps in the identity industry, a wise person came to me and said “it’s all about Venn”. And they were right! I rapidly discovered Eve Maler’s now seminal Venn of Identity:
Eve Maler, 2007; http://www.xmlgrrl.com/blog/wp-content/uploads/2007/03/venn.jpg
(For those who might not remember, CardSpace, aka InfoCard, was an early instance of an Identity Selector; it was deprecated by Microsoft in 2011.)
I soon established that Eve’s Venn of Identity was just the first carriage in a train of Identity Venns. Yes – everything in Identity could be simply and easily explained via a Venn diagram. Even really complex things like the relationship between our industry and those adjacent to it:
Ian Glazer, 2017
Higher-level ideas and developments in the identity industry could also be handily explained with a Venn. Take, for example, the rise of Mobile Device Management and Mobile Identity. Where would these concepts fit into an already well-established pantheon of identity topics? The answer, of course, lies in a Venn:
Gunnar Petersen, 2012; https://1raindrop.typepad.com/1_raindrop/2012/08/identity-in-center-stage-in-mobile-security-venn.html
Indeed, the Venn diagram soon became common currency in identity presentations. Too common, perhaps?
Paul Madsen, Brian Campbell, 2012(?)
Now, it’s true that using Venn diagrams to explain everything about Identity does rather rely on the audience actually understanding a Venn diagram:
Phil Plait, 2012; http://blogs.discovermagazine.com/badastronomy/2012/04/13/there-are-two-kinds-of-people-in-the-world/
But no matter! The Venn set me on a path to success. Whether I was building my own, adapting existing material, or simply reusing (with appropriate credit) earlier work of others, these diagrams became indispensable reference material in countless meetings where I attempted to explain to hardened systems architects and project managers why they should refactor their applications to support ID-FF, SAML, OAuth, SPML… well, OK, maybe not SPML.
Yes, 3-set Venns are the staple of our industry. So imagine my outrage when I discovered that other sectors are outstripping us!
Druhv Bansal, 2017; https://blog.unchained-capital.com/blockchain-spectrum-806847e1c575
Yes folks, that’s a 4-set Venn! Four sets! Four! And it has nothing to do with Identity. (No really – the word Identity doesn’t appear anywhere in there… )
Well, the gauntlet has been well and truly thrown down. We all know how complex, convoluted, interwoven and interdependent our Identity industry is – it’s about time we had a Venn that really represents us in all our glory. The time has come for us to reclaim the birthright of the Identity Industry.
Hence, I’m pleased to present this template for a new Venn of Identity, fit for our modern age. As you can see, it’s at the same time breathtakingly simple and delightfully complex – a perfect metaphor for digital identity, don’t you think?
Source: http://moebio.com/research/sevensets/
7 sets. Take that, Blockchain!
Now, it’s going to be a collaborative effort to complete this, but I think, if we try really hard, we should be able to have it ready for Identiverse, right! (Which year? – Ed)
Then again…. it may turn out that none of these are actually Venn diagrams.
Source: https://www.buzzfeed.com/tomphillips/also-its-pronounced-oiler
(…and worth a read, frankly – it’s a lot more amusing and well informed than this article. -Ed)
But what the heck. I’ll carry on using them anyway!
(And in all seriousness – thanks to the giants of our industry on whose shoulders we stand. Describing complex topics in easy-to-understand ways is no mean feat, and we are grateful.)
Andrew Hindle & the Editorial Committee
By Joe Andrieu <joe@legreq.com>
Three wise strangers: a rabbi, a Buddhist, and an atheist, walk into a bar… It sounds like the beginning of a bad joke, but in fact, it’s the start of a story that is probably familiar to most identity professionals.
Our religious experts are understandably initially going to interpret each other’s comments as simply wrong.
The rabbi says, “It is written in scripture that the Messiah will return one day.”
The Buddhist replies “No. He is the way, but he is not the deity.”
The atheist, in disbelief says, “You are both crazy.”
Without the awareness that each holds a different belief system, their comments about God and divinity simply don’t align. What one says about God appears to simply be incorrect to the others, and vice-versa. It’s easy to see how this could turn into a frustrating conversation.
When we gather for workshops and conferences, we often find ourselves talking with others who have a different take on what exactly we mean by “identity”. This is especially true at cross-over events like ID2020 or the International Identity Summit, where organizers make an effort to bring in a more diverse group of participants, but it rings true even at conferences catering to professionals. We’re supposed to know what identity means, right? I mean, what are all these other folks talking about?
Like these three wise strangers, we identity professionals have our own, often religiously held beliefs about exactly what identity means to us, and sometimes, when we hear others speaking from a different, and perhaps as equally deeply held belief, about what identity really means, it can be a challenge to do anything but point out how wrong they are. This makes it hard to have productive conversations.
But when the wise strangers realize they are people of different faiths, the conversation can take a turn to comparative and collective discourse rather than simple arguments about accuracy and misunderstanding. Recognizing that the others start from a different foundation gives an opportunity to explore and integrate new perspectives.
The rabbi says, “So how do you handle… ”
The Buddhist says, “That is true, we believe that means …”
The atheist says, “You are still both crazy.”
Acknowledging the perspective of others as valid won’t resolve all the differences, but it can provide a framework for mutual respect and, if you’re lucky, a foundation for areas of mutual agreement.
The rabbi says “It is good to be kind.”
The Buddhist replies “Yes. Kindness eases suffering.”
The atheist says, “Finally, you all make a point!”
Every one of us understands what we need from identity, what the pain points or opportunities our own systems and technologies help resolve or deliver. We are at these conferences because we have a need for identity. That need is real and palpable and different for each of us. These needs shape our perspectives, which in turn shape our mental models of what identity means, leading to different mental models for different identity professionals.
This is the take in “Five Mental Models of Identity”, a recently published collaborative paper from Rebooting the Web of Trust, written by myself, Andrew Hughes, Nathan George, Antoine Rondelet, and Christophe MacIntosh. In it, we explore five different, valid mental models for identity that we have seen at conferences and workshops over the last decade and more.
No doubt you’ll find your preferred perspective there, as well as the angle from those crazy guys from down the hall.
What you won’t find is support for those who shout “Stop talking about Identity! It’s confusing and overrated!”
We think identity is as fundamental to human cognition as language, and that the digital identity systems we build as identity professionals are fundamental to the emerging, evolving digital society we now live in. Identity will happen whether you design for it or not, so we would do well to think deeply about this real-world phenomenon that our digital tools help us manage. If we hope to build identity systems that can scale, with dignity, to every last child, we must incorporate the needs of everyone involved. To do that, we need to find ways to see beyond our apparent differences to understand how best we can best build systems that address the needs of the broadest population of stakeholders. Anything less will be a disservice.
It’s a quick read, so go read it. Maybe it will help conversations at your next workshop.http://bit.ly/FiveMentalModels
A robust digital identity architecture is fundamental to good security. As digital identity professionals, we frequently work closely with security teams. It’s not uncommon for the identity team to report up to the CISO. The relationship between identity and privacy is less well defined – and it’s time that changed.
In the security world, the last few years have seen a rapid and complex shift from the traditional ‘fortress’ architecture to a more nuanced, and more complicated, landscape of deperimeterization, zero-trust networks, in support of a huge shift in the range of ways people (and devices, and things) access network services. The privacy landscape is going through a similar shift.
Even if your business is not directly affected by the General Data Protection Regulation (GDPR), or by the evolving privacy landscape in North America (witness the advent of the California Consumer Privacy Act (CCPA) and the recent publication of the Privacy Framework Outline1 by the National Institute of Standards and Technology (NIST)), or by evolving regulations in China, it’s a safe bet that privacy will increasingly become an important consideration for business leaders – in many cases, a strategic imperative. This isn’t just about check-box compliance: as with identity, the c-suite is coming to understand that a solid privacy design not only reduces business risk but can also provide significant competitive advantage.
There are several key areas that digital identity professionals should focus on to help transition to a privacy-aware identity organisation. The good news is that many of these are consistent with and supportive of existing security and/or usability missions. And what’s more, these are all things you should be considering as generic good practices.
***
It’s all about data, baby!
A key outcome of most privacy (re-)design is that the amount of personal information that is collected, processed, and stored should be minimized. Asking the user only for that information which is relevant and proportionate to the reason you are collecting it is an obvious benefit to the user in terms of usability. Reducing the amount of information you are handling and storing has equivalent benefits in terms of reducing risk (particularly the potential for exposure in the event of a data breach, and, indeed, the likelihood of a deliberate breach attempt, since there is less data to go after), and reducing the cost of storing, processing, and maintaining the dataset over time.
Bear in mind that in some regulations — GDPR is one — there is a burden on you to allow individuals easily to view, update, and request deletion of personal information that you hold on them. Clearly, the less you have, the easier this will be.
Reducing the amount of information you request, process and keep is perhaps the most important adjustment you can make – although it may also be the hardest. Project stakeholders often want to collect more information than is strictly needed, and they often have very open-ended “reasons” for wanting it (which leads to overly long data retention).
Consider too whether users actually need to ‘create an account’ or whether there’s an alternative. For example: if users are federating in, you could simply use claims from the incoming assertion or ID token at runtime rather than having to persist that information in a traditional user directory or table.
Once you’re sure you’re down to a minimum, then consider who will have access to that information… and remember that this will include people on the identity team as well. Privileged access management can help here, as will safe storage of the data with appropriate encryption mechanisms.
Consider your Cloud(s)
In several of the extant regulatory regimes — again, GDPR is a standout example, but similar requirements obtain in applicable parts of Chinese regulations and associated technical guidance and to some extent in the CCPA — you will be required to track what data you send to third parties to process, and how that data will be handled.
Recognise that this may have implications for your identity architecture. Do you use a cloud directory, or a cloud-based SSO service? Do you provision users to your SaaS vendors? Do you host part of your identity infrastructure on AWS? All these might require documentation and, potentially, privacy agreements to be established.
This shouldn’t be seen as an impediment to cloud deployments! Rather, in being aware of the requirements you can better support your privacy team in their responsibilities.
Standard-bearing
Ensuring your deployments are using well-established standards, where possible, will also help you ensure a good privacy posture, and will give you fewer exceptions to check. If, for example, you have suppliers federating in to your systems, enforcing SAML and/or OpenID Connect rather than a proprietary protocol helps reduce the risk that data might be exposed in transit; and potentially reduces the need to manage and maintain additional personal information about those external users.
Keep a watchful eye on new protocols too – standards like User Managed Access (UMA)2 can be useful in some cases; and there is ongoing work in the distributed identity arena which may prove helpful over time. Equally (as the French Data Protection Authority CNIL has observed3 in the context of Blockchain), new techniques may introduce novel privacy considerations: bear these in mind as well.
***
This is not intended to be a comprehensive collection of considerations, but it should be enough to get you thinking about the areas you can help your privacy team… if you have one! Lots of companies don’t, and you may suddenly find that you have taken ownership of a privacy program yourself. If you need to learn more, there is lots of good material around that will help. If nothing else you should check out the International Association of Privacy Professionals4 (IAPP) as a reasonable place to start.
Without good identity architecture, privacy efforts are doomed to fail. In supporting privacy initiatives, though, good identity architecture also supports other security and business objectives. In some cases, the identity team can usefully take a lead on privacy projects. Start by considering your existing architecture and explore which areas you can quickly improve, and look for tie-ins that will support other initiatives within your organisation.
Andrew Hindle
IDPro Board Member, Chair of the Editorial Committee
Endnotes
1. https://www.nist.gov/privacy-framework/working-drafts
2. https://kantarainitiative.org/groups/user-managed-access-work-group/
3. https://www.cnil.fr/en/blockchain-and-gdpr-solutions-responsible-use-blockchain-context-personal-data4. https://iapp.org/
Colleges and Universities appear a lot like other businesses on the surface. They have large employee populations, lots of customers, and central IT shops that provide the same kinds of technology services you’d expect at any big company. On campuses, as in corporations, you’ll find service offerings like networking, desktop support, administrative systems, email, collaboration platforms, parking, facilities access and more.
While the services are similar, organizational culture, business practice, and customer needs are very different in Higher Ed. Technology solutions built to solve enterprise problems (especially identity management solutions) often fall flat when it comes to addressing Higher Ed needs. As a Higher Ed identity management professional, your biggest frustrations are likely to come from 1) trying to strongarm enterprise software solutions to fit the use cases at your campus, and 2) trying to educate executives from corporate backgrounds that you should not terminate a user’s enterprise credential the moment their entry in the HR system expires (among other common re-education trials).
This article gives a high level overview of 5 key areas in which identity management in Higher Education is different than in enterprise. I shared these observations in a presentation at last year’s Identiverse conference and will be publishing a blog series soon to dive into each of these points in more detail.
- Collaboration is as important as competition
Businesses tend to invest heavily in defining clear boundaries around proprietary information and services. A primary focus for enterprise security is ensuring that anyone not employed by the enterprise has as little access as possible to the stuff inside the perimeter.
In Higher Ed, on the other hand, openness is a mandate. Here are a few samples from mission statements at large research universities:
“The distinctive mission of the University is to serve society through transmitting advanced knowledge…”
“To impact society in a transformative way — regionally, nationally, and globally — by engaging with partners outside the traditional borders of the university campus.”
“The discovery and dissemination of new knowledge are central to its mission.”
A corollary to the value placed on openness is the prioritization of collaboration as much as competition. In order to achieve intellectual and scientific breakthroughs, researchers must collaborate with colleagues around the world at other Universities, research organizations, and the private sector.
Enterprise security solutions that focus on limiting access exclusively to “internal” users can be counterproductive to Higher Ed identity professionals who need to provide access to a wide range of users in a secure fashion.
- Federation means much more than bilateral SAML integration
I learned about “federated” identity within the context of a large university (one of my first jobs as an identity professional was leading UC Berkeley’s efforts to join the InCommon Federation). Later in my career, I remember being very confused when I started reading about products that had the word “federate” in the brand name, but did not conform to the standards of multilateral federation that were essential to meet our campus needs.
Multilateral federation is widely adopted in Higher Education. Multilateral federation starts with an organization, the federation, that establishes a trust framework for member organizations. The federation defines baseline practices for establishing digital identities and managing user attributes. Federation members agree to abide by those practices, and register their Identity Providers and Service Providers with the federation. InCommon is the Higher Ed and research federation in the US and the metadata aggregate includes over 500 registered Identity Providers and over 4,000 Service Providers. Federation operators around the world have further collaborated to create a combined metadata aggregate, eduGAIN, which serves as a trust framework for hundreds of universities around the world.
The adoption of federation means that one university can host a global research project, and collaborators from across the globe can log in to the project’s collaboration platform with their home institution credentials – less time creating and managing access, more time doing the research! Federation has been so successful in Higher Ed and research that REFEDS (The Research and Education Federations Group) recently launched a new international initiative to envision the next generation of Federation.
Many enterprise identity solutions claim to support “federation”, meaning a bilateral SAML integration, but do not support participation in a multilateral federation out of the box. This can be a big challenge for Higher Ed identity management staff who are trying to explain to executives why the snazzy new cloud identity solution they saw at the last conference won’t magically solve a campus’ identity management headaches.
- Collaboration extends to building and supporting open-source software solutions
The need to provide a technology framework to support research collaboration turned into a collaboration of its own. University IT staff from across the country, in partnership with non-profits like Internet2, worked together to define a common data schema (eduPerson) that would facilitate the use of shared services. Collaborative efforts resulted in the creation of an institutional framework (InCommon in the US) and software (initially Shibboleth) that enable and extend multilateral federation.
As research organizations adopted federation, their use cases spawned the creation of new open source projects to address related identity management challenges. Over the past four years Internet2’s Trust and Identity in Higher Education and Research (TIER) initiative raised significant resources through cash and in-kind developer contributions from campuses across the country to further build and enhance open-source identity solutions targeted to Higher Ed and research use cases (see Nick Roy’s IDPro article from August 2018).
By demonstrating interoperability with popular open-source solutions, commercial identity solution providers would likely gain not just better traction, but deeper appreciation and greater long-term business opportunities within the Higher Ed identity community.
- “External” Users are core to the business
Many businesses separate their identity efforts into enterprise identity and customer identity programs. Employees need access to enterprise systems, and customers need access to the company’s products and solutions. But even within the realm of “enterprise” identity, every business has users who do not qualify for an enterprise account but need access to enterprise systems. Those “external” users often include contractors, retirees, corporate alum, and collaborators.
In Higher Education, you might think of “enterprise” users as students, faculty and staff of the university, and “external” users as applicants, parents, alumni, research collaborators, continuing education students and more.
Higher Ed is like an amalgam of enterprise and customer identity in that many customers are essentially “external” users who need access to the same enterprise applications used by enterprise users. Many universities use the same Learning Management System for enrolled students as they do for programs geared toward “external” continuing education students. And parents are “external” users that log into the same enterprise billing systems used by students and staff.
When you take into account the hundreds of thousands of alumni and applicants, the number of “external” users at a university can easily dwarf the number of enterprise users. And those external users are critical to the university’s brand and funding strategy. So enterprise solutions that make it very difficult to grant access to “external” users might deliver more cost than benefit to a campus trying to streamline access to services.
- Account lifecycle management in Higher Ed has a different beginning, middle and end
Enterprise user account management is typically closely tied to the ERP. An employee is hired, entered into the ERP, and that spawns a workflow to create an identity record and prompt a user to create an account.
In Higher Ed, the user account lifecycle is different from enterprise at the beginning, middle, and end.
- Beginning – Universities often have multiple Systems of Record, such as a staff ERP, a Student Information System, and possibly an Alumni system, Medical Center, and more. A person entered as a new record in one system may already have an active record in another. So most universities build or buy an identity matching solution to reconcile these records and create an organization-level persistent unique identifier per person. This unique ID can then be easily integrated with a wide variety of identity solutions for provisioning and central access management.
- Middle – In Enterprise, an employee might change roles during their tenure, so access controls might need to be adjusted during the “middle” of an employee’s tenure. In Higher Ed, a user will often be fully terminated in one System of Record while their record in a second System of Record remains active. For example, a student might have a multiple campus job records start and terminate in the HCM before they graduate. Likewise, an active employee might return to graduate school and be added and removed from the student System of Record all while they maintain active employee status. These challenges are often not addressed well in commercial identity solutions.
- End – A common practice in enterprise identity is to revoke enterprise credentials as soon as an employee’s job record terminates in the ERP. If I had a dollar for every time a CISO or Internal Auditor asked me why former employees could still log in with their campus credentials, I would be a rich woman. In Higher Ed, users don’t leave. Their digital identity lifecycle runs in lockstep with their human lifecycle. Alumni and faculty emeriti have access for life. A former employee might be an alum, or might volunteer for the library. A mandate to terminate a user’s Single Sign-on credentials when employment ends is not consistent with the mission of the University (see point #1) and identity management solutions targeted to Higher Ed need to address the importance of managing authorization well so that users can enjoy lifelong authentication.
If you’ve read this far, chances are you either work in the field of Higher Ed identity or you provide software solutions that you would like Higher Ed institutions to adopt. If the former, I hope these points resonate with you and I’d love your feedback/input. Any big differences I missed that I should incorporate into the blog series? If the latter, I hope this articles gives you some ideas of how your products, integration plans, and/or documentation can be modified to address business needs in Higher Ed. I plan to launch to blog series next month, and you’ll find it at the Cirrus Identity blog.
Dedra Chamberlin
Founder and CEO of Cirrus Identity, a cloud-hosted digital identity solutions provider. She served as Deputy Director of Identity Management at UC Berkeley and UC San Francisco for many years. She speaks regularly at Higher Ed and Digital Identity conferences when she’s not building her company, rowing a boat, or traveling with her family. https://www.linkedin.com/in/dedrachamberlin/
Let’s say that you get it in your head to do something big, something complex, something that has a fair level of risk… such as climbing a mountain (or starting a professional organization). You stand at the bottom of the mountain saying, “I want to be up there.” Declaring the goal is easy; figuring out how to do it – and then making sure that everything is goes well – is the hard work of planning. So then how to build an effective plan?
In my day job at Salesforce, we use a technique called V2MOM to plan and to get alignment across organizations, teams and individuals; and I have brought this technique to IDPro. The V2MOM tool has been used at Salesforce since the very beginning; it is part of our culture and it is part of our corporate practice. Marc Benioff, Salesforce co-founder and co-CEO, has written about how he built the V2MOM mechanism, and shares Salesforce’s original V2MOM.
So what the heck is V2MOM? It’s an abbreviation that standards for:
- Vision: Defines what you want to do or achieve.
- Values: Principles and beliefs that help you pursue the vision.
- Methods: Actions and steps to take to get the job done.
- Obstacles: The challenges, problems, issues you have to overcome to achieve the vision.
- Measures: Measurable results you aim to achieve.
Not only does a V2MOM provide a way to plan realistically and to set priorities, but it also helps the evaluation process of taking on new work. You can use the V2MOM to measure progress, re-evaluate priority, and keep yourself honest as you do. It’s important to remember that, although the V2MOM helps to ground activities in the day-to-day reality necessary to make constructive process, it’s also intended to be aspirational.
With that, I want to share with you IDPro’s V2MOM for 2019 which the board agreed in December. First up our Vision and Values. You’ll notice that our Vision is a bit of a combination of what the Board foresees for the organization and our industry as well.
Vision
- The various disciplines of digital identity are globally seen as vital and vibrant counterparts to privacy and information security, and fundamental to good business practice
- Digital identities are created, managed, and used professionally and ethically, through secure, privacy-protecting, and reliable practices that produce high value digital services.
- Practitioners just beginning their digital identity career can learn quickly from a curated body of knowledge and from a supportive and inclusive community
- Practitioners can interact with one another in a professional and mutually supportive fashion to share best practices and to find useful approaches to real world challenges.
- Digital identity professionals are supported in all aspects of their professional development.
Values
- Respect: We recognize that diversity of background and of opinion is a strength; we promote healthy discourse; and we strive to resolve dissent professionally and courteously
- Responsiveness: We take account of the rapidly evolving digital identity landscape and adapt effectively and efficiently to stay relevant to our members and our colleagues
- Open: We promote through action operational transparency whilst respecting individual privacy
- Inspiring: We deliver world-class professional leadership for our industry and our members and our colleagues
- Inclusive: We welcome digital identity professionals from all backgrounds
Next is our Methods – these are the means that the Board has identified to help achieve our Vision. Methods have owners who are responsible for reporting progress to the Board and for arranging resources to achieve the Measures in their Method. If you want to help work on one of these Methods or have any questions about them I highly encourage you to reach out to the owner.
Methods
- M1 Body of Knowledge and Certification
- Build a body of knowledge in support of a certification program
- Owner: George Dobbs
- M2 Membership
- Grow membership in a supportable way to sustain the organization. To grow the membership IDPro must establish market awareness of the organization, its members, and its goals. This also includes providing meaningful value at industry events.
- Owner: Ian Glazer
- M3 Services
- Provide meaningful services to membership. These services should help members grow professionally and technically.
- Owner: Sarah Squire
- M4 Industry Alliances
- Establish supportable relationships with other members of the Identity industry to provide membership with value. Develop relationships with organizations in adjacent industries, such as security and privacy, to foster cross-industry awareness, collaboration, and professional development
- Owner: Allan Foster
For each Method, there are Measures – individual items that we believe help achieve the Method. At Salesforce we try and write Measures that are SMART:
- Specific: Clearly define your focus and what you’re going to do.
- Measurable: Quantify an indicator of progress, such as percentages, numbers, targets.
- Achievable: Set the bar high, yet make it achievable.
- Relevant: Ensure that the Measure supports the organization’s Methods.
- Timely: Set a specific and reasonable time frame for completion.
To be honest, not every Measure is written in this format but it’s a good goal.
Measures
M1 Body of Knowledge and Certification
- Deliver a “beta” version of the BoK by Identiverse 2019
- Acquire staff and volunteers and organize work for the selected approach, specifically a chief editor
- Deliver a plan with specific milestones, tasks and resource levels needed for selected approach
M2 Membership
- Grow membership to 900 individual members, at least 15% outside North America
- Establish a Member outreach program so that the membership can meet and interact with more of the IDPro Board
- Attain 20 enterprise/group members, representing 400% growth
- Attain 40 corporate members, representing 180% growth
- Establish routine metrics to measure progress
- In support of the organization’s need to grow members, establish a Marketing Committee
- Produce base-level marketing collateral for new prospects, onboarding process, and member retention/renewal
- Establish social media presence
- Hold meetup at RSA
- Hold meetup at EIC
- Have a major presence at Identiverse including a “Identity 101” workshop, plenary, and ID Professionals track
- “Launch” BoK work (if progress has been made)
- Increase membership engagement with Board Committees and other community functions.
M3 Services
- Continue to publish member newsletter on a regular cadence – including complete submissions & editorial process
- Deliver a new collaboration vehicle that has email and forum capabilities
- Enhance events calendar to include submission process and subscriber capabilities
- Build a speaker bureau function to help conference organizers find diverse professionals for speaking engagements
- Establish sustainable model by which Industry Analysts can contribute their research
- Publish board meeting minutes and yearly budgets.
M4 Industries Alliances
- Programmatize alliances function and establish metrics and other means of evaluating the value of IDPro’s relationships with other organizations and our mutual progress towards a share set of goals
- Formalize relationship with DIACC for the purposes of bringing a practitioner’s insight to support Canadian identity efforts
- Formalize relationship with Women in Identity to support shared diversity and equality goals
- Formalize relationship with Women in Security and Privacy to support shared diversity and equality and cross-industry collaboration
- Formalize relationship with IDSA for the purposes of member education
- Formalize relationship with FIDO for the purposes of member education
- Formalize relationship with the OpenID Foundation for the purposes of member education
- Formalize relationship with IAPP for the purposes of cross-industry collaboration in support of shared member grow and education goals.
Last but by no means least, our Obstacles. When I write my V2MOM at work, I often have Obstacles per Method and sometimes I don’t… no need to be too hidebound on this one. Writing the Obstacles section is akin to naming your fears; it forces you to express your doubts, concerns, and potential traps.
Obstacles
- Financial constraints
- The BoK will require ongoing funding for creation and maintenance. It is expected that we need $100k in additional funding
- Irregular cash flow leads to potential crunches throughout the year
- People constraints
- An all-volunteers Board and membership cannot deliver all of the services IDPro wants to deliver in 2019
- Infrastructure: using personal IT services puts IDPro at risk
- Attrition becomes a larger risk as membership begins to feel like they are not involved and not receiving value.
The IDPro Board will use this V2MOM throughout the year to evaluate our progress and re-evaluate priorities. As we update it, we will let membership know – and we value your feedback, as always. After this edition of the Newsletter goes out, we will publish the V2MOM on the website for all to see. And using this V2MOM we will climb the mountain together.
(BTW, if you want to learn a little more about the V2MOM process, you can check out Salesforce’s Trailhead module on it.)
Ian Glazer
President, IDPro
Key Elements to writing a successful proposal for a conference/speaking opportunity.
It is the time of year when industry conferences are soliciting proposals or submissions for speaking opportunities. Rather than producing yet another guide on how to write a proposal that will get accepted by conference organizers, we’re highlighting the best tips from previously written articles, providing examples, and a primer on how to write a bio you’ll be proud to share.
All the articles quoted here share common threads of advice:
- Be respectful – Use terms that are inclusive and welcoming for your intended audience (some commonly used terms that may not be inclusive: How to stay sane as a developer, 3 dumb things to avoid in …, etc.)
- Avoid buzzwords or utilizing your title as clickbait (how many times have we seen “rockstar” on a title or chosen a presentation based on a title that wasn’t actually the basis of the talk?)
- Tell a story. What is the narrative of the talk? Is there a beginning, middle, and end? Example: I will learn the basics of blockchain, how it can be applied to my particular problem, what I should avoid, and come out of the session with new knowledge to apply to my role.
- The audience is important.
- Understand your audience – consider the type of attendee that goes to the conference and, if you are writing for a particular segment, make sure that you specify the skill or experience level of that segment in the supporting details or intended audience section
- Your audience is the attendee, not the reviewer. Put yourself into the mindset of a conference attendee, one reviewing titles and deciding which sessions to go to based on the strength of your proposal. What will the attendee get from the session? In this case, use “you” more than “I” – This includes your title, abstract, key takeaways and your expertise.
- Do your research – Take a look at previous conference sessions to see if you’re repeating something that’s already been done or can offer a ‘fresh’ take of a session that was previously offered. An update, perhaps, based on relevant, new information.
- GER (Grammer, editing, reviewing) – Make sure you don’t have any typos, spelling mistakes, or other formatting errors in your proposal. Read your proposal aloud – listen to how it flows and edit accordingly. Ask a friend (or friendly enemy) to review your proposal with a critical eye.
One last piece of advice on writing a successful proposal is to be enthusiastic. If you are genuinely interested in what you’re going to be speaking about, that should come through in your writing. And by that, we don’t mean use lots of exclamation points, but, in the same vein as ‘telling a story’, put a human voice into the proposal. This is your written 50-floor elevator pitch.
Now onto your bio…
A well crafted bio is not easy to write – especially if you don’t have an experienced marketing and PR firm behind you. The bio serves two distinct needs for conference proposals and conference agendas: it tells the conference reviewer that you’re qualified to speak about your proposed topic (and is where you can insert some levity), and it helps to guide a conference attendee decision as to whether to attend your talk or a competing one, i.e. “that’s an interesting background, I want to hear what she has to say about X”.
Here are a few pointers to keep in mind as you’re writing your bio:
- Google yourself – see what the interwebs have to say or show about you. Does it align with who you really are or how you want to present yourself? If so, kudos! If not, here’s a great chance to put another version of you out there.
- Unless you’re writing a general bio, tailor your bio to the audience, highlighting relevant experiences, publications, etc.
- Define your title – if your job title is ‘Distinguished Engineer’ or ‘Developer Evangelist”, tell the audience a bit more about what you actually do
- Don’t sell yourself short! You have done amazing things; it might not feel like it but to the people in the audience your real-world experience is invaluable. Don’t be afraid to include a product accomplishment or two.
- But don’t pat yourself on the back too much. Share your accomplishments but recognize that listing all of them may put you into the bragging category.
“Writing a good bio isn’t easy,” said Ian Glazer when asked. “In trying to boil down what is interesting about your work and your life, one will often leave out the things that are probably most interesting to the reader. And don’t forgot, it’s likely someone is going to read that bio as you walk on stage… it’s the first thing the audience is going to hear. But don’t stress; have fun with your bio and make the reader has a feel for the real you.”
Should you be interested in another review of your conference submission, send us an email – we’re happy to lend an eye.
Hopefully this advice will serve you well as you seek to conquer the conference world.
Let us know how it goes.
Editorial Committee
Nicholas Roy
Director of Technology and Strategy
InCommon / Internet2 Trust and Identity Services
Internet2 is a member-owned organization which provides high-performance networking, connectivity to services and a suite of trust and identity-oriented services and software to its members. Architects of software products such as Shibboleth, Grouper and COmanage work at universities, colleges and Internet2 affiliate organizations, and have had a hand in shaping core standards such as the Security Assertion Markup Language (SAML). The InCommon Federation, a SAML trust federation serving the US and global research and education community via an interfederation partnership with eduGAIN, now provides access to thousands of global service providers from thousands of identity providers at campuses, research labs and commercial partners. Notable among these is the Large Interferometer Gravity Wave Observatory (LIGO), which recently won a nobel prize in physics. The Internet2 components provide access management for the services which LIGO researchers use to perform their work, articulated via the InCommon/eduGAIN trust fabric.
For many years, Internet2 members and others have been able to use these products free of charge, but have needed to invest significant time in understanding the underlying technologies, and that has depended on specialist practitioner skills which are in short supply. As a means to make deployment of these components easier and lower the barrier to entry in effectively using them, the Internet2 community brought together IAM architects at many member institutions during 2014, to build a roadmap for introducing DevOps methodologies, new user interfaces, new APIs and new features into the suite. A need for an entity registry and other middleware to complete the suite were identified, and a set of community-run working groups were created to document the requirements and guide implementation of the roadmap. This effort was branded as “Trust and Identity in Education and Research” – TIER.
The community, via the TIER community investor council, invested up-front capital in the project and oversaw the work and high-level strategy for the TIER effort. Most recently, the program sought a group of campuses to deploy the TIER components in their environments, work through the needed integrations and create documentation. As TIER works through the final year of its start-up funding, a sustainability model to ensure continued progress on additional roadmap items is being developed. Internet2 is also adopting the TIER components for use in its own community collaboration platform, which will automate the creation and provisioning of access to wikis, mailing lists, slack channels, etc. This automation will in turn help the community to create additional working groups and contribute back to the components.
The TIER components were originally targeted by the community to run as stand-alone virtual machine images, but as schools transition to use of containerized approaches, we have shifted to use of Docker for packaging, and will use Kubernetes for orchestration of the IAM suite at scale.
Ken Robertson
Change is constant in the IT security industry, but one thing that remains the same is attackers abusing privileged credentials. Compromised privileged accounts are responsible for many data breaches every year. What can you do to protect your organization? One way is to develop a Privileged Access Management (PAM) strategy and hire a vigilant team to implement it. There are many options available for privileged account management solutions that will meet the needs of both small businesses and large enterprises, so start doing your research. This article will explain why a PAM strategy is important to your organization and, if you have already started your PAM journey, suggestions on features you may want to include in your program, like a centralized secret manager, are discussed.
Back in January, an introduction to PAM article was featured in the IDPro newsletter. Hopefully after reading it, many of you started developing your organization’s PAM strategy the very next day. Great job! You are in good company — Gartner recently listed privileged account management as the highest priority security project that chief information security officers (CISOs) should explore in 2018. If you haven’t started your organization’s PAM program, it’s not too late to get moving. As suggested in the previous article, start marketing the idea to your management, include PAM in your strategy sessions, and make an inventory of all of the privileged accounts in your environment. These steps will help you initiate your journey into PAM.
Increased attention for PAM programs
Privileged users and accounts are not new to IT departments. Application owners and system administrators have used privileged accounts to access critical systems for decades. What has changed to make privileged account management a top initiative for CISOs in 2018? There are many reasons, but it starts with managing risk within your organization. Countless data breaches could have been prevented by managing privileged credentials. CISOs understand if a privileged account is compromised, the risk to the organization is significantly greater because the attacker now has the ability to penetrate a larger portion of your environment (or of that system), with less chance of being detected, and with access to more sensitive data.
Another reason for the increased attention for a PAM program is due to the explosion of the number of privileged accounts in an organization. Executives are surprised to learn that they have significantly more privileged user accounts than employee logins. A survey conducted in 2013 determined that the number of privileged accounts in an organization is typically 3-4 times the number of employees. We know that ratio is even higher today due to increased use of automation with RESTful APIs, configuration management tools that can login to every server in your infrastructure, and VMs and containers that can be created by the thousands in seconds. The sheer volume of privileged accounts can make it difficult for organizations to manage.
An additional reason that CISOs are looking at their PAM program is due to a “back to basics” movement in security that has been going on for many years. The movement started as a cost saving proposal to automate and improve processes that were considered basic, yet foundational, areas of security. The impediments holding back security organizations are not related to technology, they are often related to processes.
Don’t assume basics are easy, because they are not. The basics are hard. The larger your organization, the more privileged accounts you need to manage. Fixing privileged access issues in legacy applications can be a huge challenge, especially when the original implementors are no longer with your company and the remaining staff has limited knowledge of how things work. Yet, it is precisely this type of application that an attacker will take advantage of to gain access to your data. The privilege access issue needs to be fixed or the application needs to be retired.
Efficiencies gained through automation and removing the human element from tedious tasks will strengthen your organization’s security posture, free up skilled resources to work on more challenging tasks, and save money. Consider this: does it make sense to fund projects for the latest and greatest security scanning tool if you know that you have gaps with privileged access management? No, of course not. Funding for your PAM program will have a better return on investment and will also shore up the foundation for your whole security organization.
Prioritize accounts based on risk
Every organization is different and will have different strategies for success. There is no single formula or magic bullet for implementing PAM that will work for everyone, but there are a handful of common risks found in most organizations. Operating system, domain admin, and database admin accounts are a good place to start. Phase your PAM program in using a risk-based approach and implement on highest risk systems and accounts first. Have a clear strategy for your program before selecting any PAM tools.
Your organization will want to define what makes an account privileged and what is considered high risk versus low risk. Without these definitions, system administrators and application owners are left to decide what should be considered a privileged account and they may miss including critical accounts in your inventory.
There will be many different types of privileged accounts in your environment, so as mentioned above, part of your PAM strategy and risk assessment is to identify and categorize them. The account’s level of privilege could come from its ability to change or modify user access, change system configurations, and change security settings. The privilege could also come from the classification of data that it can access, if that data is monetizable, or if the account could be used to harm a business’s reputation. Leaving social media accounts unmanaged puts your company at risk of possible brand damage. Often, account access is shared across multiple people and they are only protected with a username and password.
There are many resources online to help you with identifying types of privileged accounts, but here is a quick list of some of the common ones:
• Local admin accounts on servers
• Admin accounts for applications and databases
• Admin accounts for your Active Directory domain
• Emergency / fire call accounts to be used for recovery or troubleshooting
• Service accounts used by applications
• Application accounts used to connect to databases
When creating your privileged account inventory, it is easy to overlook some types of accounts. Here are some of the privileged account types that are commonly missed:
• API keys used by applications to connect to other applications and services
• SSH keys used by humans and applications to connect to OS
• Social media accounts for apps like Twitter, Facebook, and LinkedIn
• Cloud console accounts for AWS, Azure, and Google Cloud
Centralized Secret Managers
A relatively new feature in the PAM toolbox is a centralized secret manager for handling credentials for API keys, database connections, configuration management, containers, and your DevOps pipeline.
You may think that you already have this use case covered with your enterprise password manager, but in many cases, your traditional tools will not be able to keep up with the demand. Secret managers are optimized to handle highly automated environments, like your CI/CD pipeline and your configuration management and build systems. You can think of a secret manager as complementing your existing password manager.
A big part of setting up DevOps tools is about configuring the secrets that will allow them to communicate with other apps and services. Configuration management tools, like Chef, Puppet, etc. have localized secret managers built into them to be used for installing software and for connecting to operating systems, data bases, and APIs. Each tool manages its own set of privileged credentials, with different access controls and different logging capabilities. Access to the data isn’t always logged, so if you have an intrusion, it isn’t clear what data has been accessed and by who. Every tool becomes its own island of accounts and security controls making it impossible task manage.
This is where a centralized secret manager can help you. The key here is centralized and not tied to any specific automation tool. From a risk perspective, it becomes very difficult to manage the highly privileged credentials when they are scattered all about. A centralized secret server can be utilized by all of the tools and services in your organization and your PAM team will be able to manage and monitor the secrets while not getting in the way of the automation.
There are several secret managers available that have both an open source version as well as an enterprise version. This is great because it will allow your team to install and test in your environment and determine the value that they provide.
Conclusion
PAM is a trending topic right now, and for good reason. Privileged accounts are being abused by both external and internal threats and that is going to continue. In general, the number of privileged accounts greatly exceed the number of user accounts and staffing needs to be able to appropriately handle the volume. PAM is more than password management. It is necessary for organizations of every size to have a strategy around how they will handle privileged accounts. PAM is a program that can be started immediately to significantly reduce risk, secure information and provide a positive business impact.
If you come from a software engineering background, the tradeoff between requirements, quality and delivery dates is one you’ll be intimately familiar with. In corporate or transaction law, there is a natural tension between facilitating deals promptly and with least friction whilst satisfying critical legal and policy obligations. Investment professionals balance risk against return with every trade they make or advise.
I’m increasingly struck by one of the balancing acts we need to perform in the digital identity profession: ‘knowing’ who someone is, whilst affording them an appropriate level of privacy and security.
“Appropriate” and “knowing” are perhaps dangerous words to use: they are open to wide interpretation, and will change with context. Different transactions have different needs; different societies or interest groups have different sensitivities and tolerances.
There is, however, an increasing and noticeable trend in the direction of the use and sharing of ‘verified’ attributes which warrants careful consideration. There are absolutely cases where such sharing has value – permissioned sharing in the provision of financial services, for example, holds much promise in terms of driving down the costs of regulatory compliance, providing better security and improving customer service and access. There are also examples where the quid-pro-quo is perhaps less clear – age verification? Registering an account to read an online publication (not comment – just read)…?
There are other areas where balance is important. In this month’s issue, you’ll find the second part of Ken Robertson’s series on Privileged Access Management (if you missed Part I, you’ll find it in the January 2018 issue). PAM is a critical part of an identity (and system) security strategy; as Ken points out, the success of a PAM program depends in part on understanding which systems to protect first; how to protect legacy systems; and which technologies will best fit the needs of the organisation as a whole. In other words: balancing the identity security priorities against the other daily needs of the business.
Finding balance is one thing, keeping it is another! These are hard questions – finding answers (and convincing others that you are right) takes time, effort, and energy. It’s all too easy to sit back at that point – but circumstances change, technologies evolve, challenges mutate. Sometimes, that means the answers will change too. That doesn’t mean the original answer was wrong; just that it’s wrong now. It’s OK to course-correct, if that’s what the situation requires.
Of course, you might also find you need to balance a change of direction against a strongly held principle… but in the interests of balancing my desire to get into the topic of ‘principled identity management’ and the word limit for the editorial, perhaps I’ll leave that to another time.
Andrew Hindle
Chair, Editorial Committee
Board Member, IDPro
The purpose of this survey was to gather additional points of view to facilitate the development of a body of knowledge program.
Twenty seven IDPro members took a survey from June 1st to July 8th, 2018. Responses were voluntary and self-selecting. Despite being decidedly unscientific the results are valuable as we select goals and methods.
Key takeaways
Respondents who indicated they would like to continue the dialog indicated their country. Respondents are from USA, Canada, Germany, and the United Kingdom.
- Interest is evenly split between catering to entry level and experienced professionals.
- Self-paced course ware seems to be popular. Developing text as the reference mode should be done with courseware in mind.
- The most important other audience (other than ID Professionals) is clearly Enterprise Management. A substantial number of people, however, see the public as an important target.
- Infographics style should be used for both of the above audiences – probably with different content.
- There is a strong interest in continuing education at all levels of experience
- There is an opportunity to enable in-person training (how as yet unknown)
- Web based instructor led training is more important than in person training
- Self-paced online training is the preferred method of training.
- A majority of the respondents think certificate of completion would be valuable. But a significant portion does not see the value. Such an offering could be a stepping stone to a formal certification.
- See below for a priority ranking of high level topics and other suggested topics
- The split on the deep vs wide phasing question indicated that a hybrid approach may be advisable if it can be managed.
- The use of existing materials should be undertaken judiciously.
- Regarding sources of resources: This will need paid staff. There was a high expectation of volunteers (perhaps due to self-selection?) a significant belief that resources can be acquired from corporate and enterprise members.
- There was a strong belief that professional writers and editors are needed at least as part of the mix.
- The self-selected group is very sanguine about their firms’ interest in assisting.
Ordering of original topics
| Rank | Topic | Score |
| 1 | User Authentication | 3.29 |
| 2 | Single Sign-On & Federation | 4.25 |
| 3 | Access Management | 4.68 |
| 4 | Identity Governance and Administration | 5.28 |
| 5 | Customer Identity Services | 5.80 |
| 6 | Identity Proofing | 6.00 |
| 7 | Privileged Access Management | 6.35 |
| 8 | Privacy | 7.00 |
| 9 | Best Practices | 7.88 |
| 10 | Laws & Regulations | 8.21 |
| 11 | Identity Analytics and Intelligence | 8.32 |
| 12 | Identity Hygiene | 9.45 |
Other topics to consider
- Access Control (different from Access Management) with Service-to-Service flavor, User Context propagation
- API management, IoT device management
- Consent specifically apart from privacy might be useful
- Credential Management,
- Cyber Security patterns for all of the above
- Cybersecurity as applied to identity
- Directory Services and Identity Data Management,
- Global and Unified B2E, B2B, B2C IAM strategies for large enterprises
- Having a technical stream vs management stream might be a good way to go. Often you won’t have the same practitioners.
- IAM Program[me] Governance
- Intersecting identity and security
- IRM
- Layered security with regards to authentication
- New trends and technologies
- Omni channel identification/ authentication
- SSDLC
- Standards
- Tools or best community practices
- Tools to assess identity systems such as score card assessments.
For a copy of the report write to info@idpro.org or download from the idpro.org members site.
George Dobbs
IDPro Board Member
Identiverse is always overwhelming. So many sessions. So many people. So many great conversations. But this year’s was especially so.
First, the biggest takeaway for me was the noticeable maturation of identity conversations. I got the sense that, although we still struggle with deployments and systematizing the fundamentals, we are beginning to extend our gaze towards the horizon a bit more. We are looking towards the unfolding future state of our businesses, our internet, and our societies and seeing opportunities like we never have seen before.
Wow have we grown! My second takeaway was that our ranks have increased. Seeing the 2000 or so of us in sessions and on the expo floor was really amazing. One of the best indicators of our growth was the Women In Identity lunch and how packed it was! Kudos to Pam Dingle, et al for continuing to build a great community. And special thanks to Pam for having Kriti Sharma address the group!
This growth has also come with expected growing pains and those willing to help ameliorate those pains. I had many conversations about how challenging it is to build new identity professionals. I had an equal number of conversations with people who said simply, “I want to help.” Up until recently, IDPro was not prepared to facilitate this participation. Honestly, I’m not sure we are 100% ready but I don’t want to let great be the enemy of good. Our fellow professionals need help and it’s time to do more. Here are areas where the industry and IDPro could use help:
- Mentors – I talked about mentorship in my keynote. Nothing can turbo charge a professional like having a mentor. And I can personally attest that being a mentor is an immensely satisfying endeavor. And if you don’t think you have what it takes or that you aren’t senior enough, let me tell you right now that that is the sound of imposter syndrome. Even if you have only been in the industry for a few years, you can be a mentor. You can talk to what you felt and what you learned just starting out. In some ways that is more relevant advice than the whimsical musings of someone who might have more years in industry… “Back in my day I rode a DAP directory to work everyday uphill both ways in the snow, etc.”
- MeetUp Speakers – the number of identity-related meetups is growing and the need for speakers grows along with it. If you want to talk about something you accomplished or an innovative use of identity technology or your personal growth in the industry, there are definitely places to do so.
- Editorial Committee – I know you’ve got something cool to tell everyone and I also know some of you want to help us produce this newsletter and such as well. Your help is needed!
- “Voice of the Practitioner” – IDPro has signed a memorandum of understanding with DIACC to help their work on an identity curriculum. DIACC is working with the Canadian government along with four higher education institutions to create educational materials. IDPro members are going to help review these materials and make sure that they are practical, applicable, and understandable. And I guarantee you this won’t be the last time we help another organization in this way!
- Body of Knowledge – IDPro wants to begin work on the Body of Knowledge shortly. We will be forming a committee to help guide and oversee this work. If you haven’t taken the Body of Knowledge survey, please do so to help us shape the work. The Board met after Identiverse and the Body of Knowledge was one of the primary foci of our meeting. I feel good about the early plans we have here and I am excited to kick off the work.
So how do you help? It starts with a simple email to iwanttohelp@idpro.org. Drop us a line, tell us how you’d like to help and we will go from there!
Finally, it was amazing to see IDPro’s presence at Identiverse. For the first time ever we had a booth equipt with all the trappings. Seeing the IDPro sign, our “flag”, at our booth was really something. Even more so was to see all of the sessions about the identity profession and professionals. Once session recordings are up we will consolidate the list of IDPro-related sessions and get them out to everyone. Thank you to everyone who represented IDPro on stage, on the expo floor, and in the hallways. Thank you to Omada for helping co-host our first happy hour. And most importantly, thank you to you, our members – the energy you bring to this industry, this organization, and each other is deeply appreciated!
Ian Glazer
Founder and President, IDPro.org
David Birch
There’s a bit of a row going on about social media and bots. The noted entrepreneur Mark Cuban, for example, caused some debate recently by saying that…
It’s time for @twitter to confirm a real name and real person behind every account, and for @facebook to to get far more stringent on the same. I don’t care what the user name is. But there needs to be a single human behind every individual account .
— Mark Cuban (@mcuban)
January 28, 2018
He’s wrong about the real name, because anyone familiar with the topic of “real” names knows perfectly well that they make online problems worse rather than better. Last year, the dating platform OKCupid announced it would ask users go by their real names when using its service (the idea was to control harassment) but after something of a backlash from the users, they had to relent. Why on Earth would you want people to know your “real” name? That should be for you to disclose when you want to and to whom you want to.
In fact the necessity to present a real name will actually prevent transactions from taking place at all, because the transaction enabler isn’t names, it’s reputations. And pretty basic reputations at that. Just knowing that the apple of your eye is an actual person is probably the most important element of the reputational calculus central to online introductions, but after that? Your name? Your social media footprint? (Look at the approach of “Blue”, a dating service for Twitter-verified-users-only.)
I don’t think this is a solution, because if I were to be on an internet dating site, I would want the choice of whether to share my name, or Twitter identity, or anything else with a potential partner. I certainly would not want to log in with my “real” name or anything information that might identify me. In fact, this is an interesting example of a market that does not need “real” names at all. “Real” names don’t fix any problem. Your “real” name is not an identifier, it is just an attribute and it’s only one of many elements that would need to be collected to ascertain the identity of the corresponding real-world legal entity anyway.
While Mr. Cuban is wrong about the “real name” issue, he is absolutely right about the “real person” issue. Let me use a specific and prosaic example to explain why this is and to suggest a much better solution to the bot problem. The example is internet dating, a topic on which I am a media commentator. Or at least I was once.
Real People, Real Use Case
A few years ago, I appeared on a programme about internet dating on one of the more obscure satellite TV channels. They wanted an “internet expert” to comment on the topic and since no-one else would do it, eventually the TV company called me. The show turned out to be pretty interesting. I didn’t have much to say (I was there to comment on internet security), and I can’t remember much of what was said, but I do remember very clearly that the psychologist at the heart of the show made a couple of predictions. While interviewing a couple who had met online, she said (paraphrasing greatly) that in the future people would think that choosing a partner when drunk in a bar is the most ludicrous way of finding a soulmate, and that internet dating was a better mechanism for selecting partners for life. Now it seems that this prediction is being confirmed by the data, as the MIT Technology Review reports that “marriages created in a society with online dating tend to be stronger”.
The psychologist’s other prediction was that internet dating gave women a much wider range of potential mates to choose from and allowed them to review them in more detail before developing relationships. Of course, internet dating also increases the size of the pool for men, but as I remember (and I may be wrong on this) her thesis was that men don’t seem to make as much use of this as women do. Anyway, the general point about the wider pool now seems to be showing up in the data, assuming that interracial marriages are a reasonable proxy for the pool size. When researchers from the National Academy of Sciences looked at statistics from 1967 to 2013, they found “spikes” in interracial marriages that coincided with the launch of online matchmaking sites.
Why am I telling you all this? Well, it’s to make the point that internet dating is a mainstream activity that is having a measurable impact on society and yet it is rife with identity fraud of every kind. There are two basic problems that we have made essentially no headway in tackling over the past couple of decades.
The first problem is that you do not know who you are communicating with online, a problem that has remained essentially unchanged since the earliest days of the internet.
Every morning I wake up to the same routine. I log into the Tinder account of a 45-year-old man from Texas — a client. I flirt with every woman in his queue for 10 minutes, sending their photos and locations to a central database of potential “Opportunities.” For every phone number I get, I make $1.75. I’m what’s called a “Closer” for the online-dating service ViDA (Virtual Dating Assistants).
Well, that’s a great example of a job that didn’t exist a few years ago, but $10 an hour doesn’t seem like much for whats seems to me to be quite hard work. All of the stuff about verified accounts and such like doesn’t really help with this basic problem. Actually, verified accounts don’t really help with anything at all. People who have verified accounts sell them for bots to use anyway (an example of this is the Fuelgram service).
So not only do you not know who you are engaging with, you don’t even know if they are a real person or not, which is something of an issue when it comes to dating.
These activities suggest to me that online dating is a much better use case for mass market digital identity.
It is a better test of scale for an identity solution than logging on in your real name to do taxes once every year and it also provides a realistic path for digital identity into the consumer market.
Get Real
What internet dating needs, and what will solve Mark Cuban’s social media problem as well, is the ability to determine whether you are a person or a bot (remember, in the famous case of the Ashley Madison hack, it turned out that almost all of the women on the site were actually bots). On Twitter it’s not quite that bad yet, because there are still many people posting there, but with bot networks of 500,000 drones tweeting and re-tweeting it is not in good shape. The way forward is surely not for Twitter to try and figure out who is a bot and whether they should be banned but Twitter to give customers the choice. Why can’t I tell Twitter that I don’t want bot followers, that I want a warning if an account I follow is a bot, that I don’t want to see posts that originated from bots that I don’t follow and so on.
Just as with internet dating, the problem is not real names but real people.
Now, working out whether I am a person or not is a difficult problem if you are going to go by reverse Turing tests or Captchas. It’s much easier to ask someone else who already knows whether I’m a bot or not. My bank, for example. So, when I go to sign up for internet dating site, then instead of the dating site trying to work out whether I’m real or not, the dating site can bounce me to my bank (where I can be strongly authenticated) and then the bank can send back a token that says “yes this person is real and one of my customers”. It won’t say which customer, of course, because that’s none of the dating site’s business and when the dating site gets hacked it won’t have any customer names or addresses: only tokens. This resolves the Cuban paradox: now you can set your preferences against bots if you want to, but the identity of individuals is protected.
One of my acid tests of whether a digital identity infrastructure is fit for the modern world is whether it can offer this kind of strong pseudonymity (that is, persistent pseudonyms capable of supporting reputations). If we can construct an infrastructure that can deliver these to the world of internet dating, then it can deliver them for cryptocurrency, cars, children and all sorts of other things we want to manage securely in our new always-on environment. We have to fix this problem, and soon, because in the connected world, if you don’t know who IS_A_PERSON and who IS_A_DOG and who is neither, you cannot interact online in a functional way.
About the AuthorDavid Birch is an author, advisor and commentator on digital financial services. Hie is Director of Consult Hyperion, the secure electronic transactions consultancy, and a Visiting Professor at the University of Surrey Business School. An internationally-recognised thought leader in digital identity and digital money, he was named one of the global top 15 favourite sources of business information by Wired magazine. Dave’s web site is www.dgwbirch.com
Let me start this report with an important announcement: we’re updating our privacy policies…. Just kidding! But I’m sure your inboxes have been filling up with a number of similar notifications as the European GDPR regulations became enforceable. It was appropriate then that just a week prior, the largest identity conference in Europe took place outside of Munich, Germany.
This year I was fortunate enough to be able to attend my first ever European Identity & Cloud Conference (EIC). It’s an event that I have wanted to attend for a long time, jealously reading other attendees’ tweets, but I have had a difficult time justifying an overseas trip in a corporate environment where every budget dollar is an important asset. A judicious combination of a cheap airline route, an inexpensive little B&B in Dachau, and, most importantly, KuppingerCole’s generous offer to come speak about IDPro allowed the fulfillment of this desire.
While I was expecting some differences to the RSA, CIS, and Gartner conferences I have attended in the States, the biggest contrast was in the format of the conference sessions themselves. Keynotes and the sessions (in five different tracks) typically ran from about 9am to 7 or 8pm. Almost all of those sessions, including the keynotes, were just 20 minutes in length, which meant it was possible to attend about 20-25 different sessions each day. It was definitely the mental equivalent of drinking from a firehose.
The plethora of sessions also meant, however, that almost every subject within the vast pantheon of the identity industry was being discussed at one time or another. While sessions on the impact of GDPR were prevalent, even they were outnumbered by sessions about Blockchain. Whether it was talks about Decentralized Identifiers, Self-Sovereign Identity, or even Canadian Blockchain, there were no less than 30 sessions around decentralized ledger technology, demonstrating that there are still very smart people having very serious discussions about this technology. Other popular topics were advances in identity standards, FIDO2, CIAM, PSD2, PAM, identity governance, and privacy.
There was also a collection of three sessions around IDPro. This group of Wednesday sessions was kicked off by an incredibly well-researched and informative session on developing identity talent within your organization by IDPro member, and Director at Deutsche Bank, Olaf Grewe. He’ll be reprising the talk in a couple of weeks at Identiverse (formerly known as Cloud Identity Summit): make sure you attend! I got to follow that with a talk titled “What Every ID Professional Should Know” covering one of my favorite topics: the benefits of the community of IDPro members. The track finished up with Olaf and I being joined by Microsoft’s Pam Dingle and Identiverse Content Chair Andi Hindle for a panel discussion about the future of the identity profession. It was a great experience and I was honored to be able to participate in it.
As with most conferences, the opportunities for personal interaction with other identity professionals were just as valuable as the sessions themselves. On most evenings there were numerous different groups forming for dinner, drinks, or even just group chats. It was a great occasion to catch up with old friends, but the European location provided a chance to meet a whole new audience and I was happy to form a number of new relationships that I hope to maintain for years to come.
The EIC was extremely valuable to me and has definitely earned a spot on my annual conference attendance list. I cannot wait to return next year!
Steve Hutchinson
Board Member, IDPro.org
Dan Blum
Identity Professionals often struggle to identify and obtain funding for improvements they believe are critical to the business. To help make better connections to funding, this article publishes initial results from our (still open) survey on organizations’ top IAM drivers. It also recommends good practices for identifying your organization’s top drivers for IAM and closing the gap to funding.
Figure 1: Top IAM Funding Drivers Survey Results
The chart above shows the initial results from a survey we’ve promoted on our blog [1], LinkedIn, Twitter, and via ID Pro as well as IAM User Groups in the U.S. Our respondents are primarily worldwide identity or security professionals from multiple industries responding on behalf of their employers or clients. For more information on these results, a detailed recap will be posted here [2]. Note that survey is still open [2] and you’re welcome to add your response. Our goal is to eventually get enough responses to be able to slice and dice by region, industry, and other parameters.
Surprising?
In some ways the survey results aren’t surprising. Few respondents identified drivers we hadn’t already put on the menu. However, they ranked them a bit differently than we had expected (as shown in the mind map below).
Figure 2: Survey Results (Top 1-5) we Expected to See
Although Compliance was the top driver from the survey, respondents were primarily concerned with its audit-focused sub-category. We expected privacy-focused compliance would rank higher with the May 25 EU GDPR deadline looming when we initially ran the survey – especially considering anecdotal evidence that many organizations aren’t fully ready for GDPR. We also expected more uptake for “reduce costs.”
Good Practices and The Key to Funding
Security Architects Partners believes the reason for our funding struggles is that IAM programs are cross-functional in nature. HR, Legal, Security, Compliance, Marketing, Finance, and diverse business units (BUs) all have a stake in IAM, but none of them really own it. One of our favorite books – Crucial Conversations [3] – cites research that “80% of the projects that require cross-functional cooperation cost far more than expected, produce less than hoped for, and run significantly over budget.” No wonder they’re hard to fund in the first place!
Although one can sometimes simplify IAM projects to reduce stakeholder inter-dependencies, organizations must embrace cross-functional engagement to make IAM work overall.
Tip: Don’t treat getting IAM funding as a one-and-done chore you’d rather avoid; instead IAM leaders should work to form and sustain stakeholder relationships using soft skills at facilitation and dialoguing (aka crucial conversations).
Manage the IAM Funding and Delivery Cycle
We recommend weaving the endless quest for funding into an ongoing IAM program for stakeholder engagement. Manage the four interlocking, iterative steps shown in Figure 3. Note that each step may seem easy enough, but IAM leaders must learn the good practices and the pitfalls.
Identify and Claim Your Funding Drivers
Begin with a set of strawman funding drivers you think are applicable to your organization by refining those on the mind map in ways that make sense for your organization or industry. For example, we just finished an IAM Strategy and Roadmap project for a well-known engineering services company. Their top driver is “brand protection” followed by “reaping revenue from customer-facing applications.” These drivers do map to compliance and user experience, but it is best to coin distinctive names for them that your stakeholders will relate to.
Pitfall: You may start with a good list of drivers but consider it a living document. Don’t get pigeon-holed by failing to look far and wide for new drivers, and new perspectives on drivers.
Connect with Stakeholders
The obvious IAM stakeholders include security, compliance, enterprise architecture (EA), HR, legal, privacy office, badging, marketing, and finance. But there are more. To find them, leverage staff’s institutional knowledge of who’s who and consider circulating surveys to find known IAM needs in BUs. Once you identify the stakeholders, connect with them through one-on-one outreach, focus groups, and other awareness and communication efforts. You need to make each stakeholder see their operational, compliance, and business-enabling IAM needs and ways that your proposed roadmap can fulfill them. Until each stakeholder has helped you refine your funding drivers further, you may not have really connected with them.
Pitfall: Some organizations have been hollowed out by outsourcing, cloud-sourcing, offshoring, and high levels of staff turnover, downsizing, and retirements. Institutional knowledge may be limited. Morale and/or trust in IT may be low. This can make it difficult to locate all the stakeholders, or to get good survey responses. But don’t give up! EA, Finance, and Security colleagues can help by providing IT- and BU-level budgets and strategic plans. These and other artifacts – such as application identity repository content or even activity logs – can provide vital clues as to where excessive costs of IAM silos, IAM-less business processes, and other pain points or unmet needs exist. Where there’s an IAM pain, there’s a potential stakeholder. Just ask around until you find the project, application, or artifact owner you think may be in pain.
Building the Business Case
If you’ve refined your funding drivers and connected with stakeholders, the business case won’t be hard to build. The idea is to lay the groundwork early in the funding and delivery cycle. Then formalize information from your discovery efforts as follows:
- Identify prioritized gaps, issues, and solution requirements
- Quantify current process costs and resources
- Specify program goals
- Quantify or justify benefits
- Develop a financial model that suits your stakeholder and sponsor budgeting styles
- Identity investment costs, including net opex and capex increases or reductions
- Quantify any risks reduced
- Include any other tangible (i.e., revenue increase) or intangible business benefits
Pitfall: Trying to get funding for the common good by passing the hat can be a hard sell – except to those stakeholders that realize an immediate tactical benefit. Don’t ask all your stakeholders to sacrifice, do ask them to support you as the business case goes to up the chain to C-level approvers that will, hopefully, become project sponsors. The more stakeholders behind the business case, the better the credibility.
Tip: We recommend using Factor Analysis of Information Risk (FAIR) to quantify risk reduction. FAIR can help you build scenarios to quantify both the worst case and annualized costs of not having the right controls, and also identify systemic controls that help with multiple risk scenarios. We try to use FAIR, at least at a high level, in all our business case development or architecture improvement engagements to help clients prioritize and organize roadmap activities.
Tip: Even if you don’t get all the required funding at first, keep your eye on the following long-term goal: Institutionalize the funding and delivery life cycle by establishing a truly cross-functional identity governance structure.
Implement value
Well-defined business drivers, a good business case, and strong stakeholder communications are the keys to implementing the IAM capabilities your organization most needs, and to make sure stakeholders have your back. At this point, you can focus on delivery: Implementing value through a solid roadmap, well-executed projects, and some early wins.
IAM Leadership
Hand in hand with every business case, implicitly or explicitly, make the Big Case for identity governance. Even if the organization already has an IAM Steering Committee, be sure it stays relevant. Maintain buy-in, attendance, interest, and awareness. There lies the long-term future of IAM funding and the whole IAM program.
Conclusion
As with so many things in life, institutionalizing the identity funding and delivery cycle is about the journey as much as the destination. By following the strategies in this White Paper, you should be able to land the funding needed.
In the process you will have brought together existing stakeholders and discovered new ones. You will have refined the funding drivers and played them back to the stakeholders. You will have created a cross-functional team to help articulate the business case and sell the program to executive sponsors. You will have engaged the sponsors and stakeholders in an IAM Steering Committee to provide ongoing identity governance.
References and Links
- http://security-architect.com/all-blog-posts/
- http://security-architect.com/iam-funding-drivers-survey/
- Patterson, Kerry, et al. Crucial Conversations: Tools for Talking When Stakes Are High. 2nd ed., McGraw-Hill, 2012.
About the Author
Dan Blum is a Principal Consultant with Security Architects Partners, a consultancy specializing in identity management, security, and risk management. He supports global companies with identity/security/risk assessments, architectures, roadmaps, workshops, solution evaluations, and more. He also provides business development, research, and high-quality content for security software and service providers. He has broad industry exposure as a Senior Analyst at KuppingerCole (current), former Gartner/Burton Group VP, and involvement with multiple security and identity associations and standards groups over the years.




























