Dick Hardt

I will take rather funny and not boring as a rating for any panel I participate in anytime, but it is true that the members of the closing panel at #Identiverse did not get overly technical about the 25+ years we each have spent in this industry or what we see from then that applies to now. Luckily, we can talk about it here instead. I get deja vu these days in the comparison between user directories and agent registries. There was a point early on when the directory standards were there but the data practices were broken. Identifiers containing volatile information were used as primary indices in the directory and when that volatile data changed, chaos ensued. I don’t know how many of you remember those days, days when it was difficult or impossible to change your last name, when changing your corporate loginid was different degrees of impossible depending on which systems had to be modified, because some of them treated login ID as immutable database keys, others couldn’t be changed without a backend database search & replace. In some applications the change was impossible because other users had already claimed the loginid that would have kept referential integrity across the system. This, by the way, is part of why the SCIM protocol uses the “externalid” attribute in the spec - it helps both the client and the server to maintain decoupled referential integrity. All of the major directories eventually moved to using primary database keys that were not only GUID based but immutable and never reused. I am a big fan, but that doesn’t stop me from seeing parallels with client identifiers from protocols like ClientID Metadata Document (CIMD). CIMD claims an identifier for clients that seems stable but is in reality volatile in predictable ways. As mergers, acquisitions, products and versions change over time, different parts of the identifier will change too. The pain of maintaining existing relationships while changing the identifier will be real. With both agent registries and OAuth authorization servers collecting and storing that information, I imagine we will see who has put the thought in and who has not, because the attack vectors are predictable too. About a decade after we learned our lesson with directory accounts, we had a related issue with OpenID 2.0 identifiers, where we were dealing with relying parties across the internet rather than applications within a corporate perimeter. Nobody cared about the problem to start, because everyone was all about the happy path but eventually users wanted to establish new OpenID 2.0 identifiers stored at relying parties but needed to prove there was a relationship between the old claimed identifier and the new. The result eventually was the OpenID 2.0 migration protocol: (https://lnkd.in/gFVnwcnh). Will we need something similar for client IDs? Maybe Ian, Eve, Andrew or others who were there back then can weigh in!