A major research university with multiple overlapping identity stores had a cumbersome and inefficient means of assigning identifiers to "new" users, resulting in hours of manual labor each week as identity administrators sought to sort out which users were truly new and which were existing users.

• Fact Finding: Interviewed identity administrators, SMEs on the identity stores (database programmers and Java programmers), and end users (themselves administrators). Quickly developed a deep understanding of the existing systems and processes.
• Architecture Drafting: Architected a system of small, reusable services for finding people and assigning identifiers. Further, architected an identity de-duplication app that used the small services to greatly streamline the identity administrator's tasks.
• Documenting the architecture and the app: created a set of diagrams and text descriptions for the architecture. Did the same for the app, plus created screen mockups
• Soliciting Feedback: created and gave slide presentations on the architecture and what it addressed. Provided "demos" of the app via the screen mockups. Did slight revisions to both based on the feedback (e.g. adding a "work notes" section to the identity de-duplication app).

The identity administrators were delighted with the de-duplication system I designed. This system awaits development. A variant of the system I architected for finding people and assigning identifiers was deployed in 2016 and remains a core part of the identity and access management infrastructure for the university.

Internet2—a consortium of US colleges and universities— had received a grant to create a "consent" system that was appropriate for the intricacies of the higher education environment. A higher education institution holds a lot of sensitive personal information about its students, staff and faculty. The institution typically wants to offer its users some control over the release of their personal information, but just how much control depends on the receiving party, the user's role, and other possibly complex factors. No one within the Internet2 community of architects had come up with an architecture that could address this situation.

• Fact Finding:
  • Drew on the extensive interviews of stakeholders—end users, system administrators, developers, and managers—that I'd done for two other identity management projects at a major university. These included discussions on the release of a user's personal information and when it might be appropriate to ask for the user's consent. I always take extensive notes during my interviews; these notes allowed me to refresh myself on the valuable information I'd already been given.
  • Did a new interview with the architect of a widely used identity management system that included limited consent functionality.
  • Researched other consent systems; assessed what was working well and not so well for each stakeholder (i.e. end users, system administrators, etc.).
• Architecture Drafting: Considered what would be a excellent fit for higher education—a system that allowed for both institutional policies and user policies on personal information to be considered—and came up with a draft architecture.
• Internal Testing of the architecture: Drew diagrams of the flows between components that addressed the existing use cases.
• Documenting the architecture: After seeing that the draft architecture "worked," wrote up a document detailing the architecture, policies, and functionality it supported. In this document, discussed how this new consent system fit in with an existing popular identity management system
• Soliciting Feedback: Sent the architecture document to an Internet2 "Scalable Consent Team" consisting of multiple architects, developers, and project managers. Created additional diagrams to further help analysis and understanding. In this particular case, the feedback helped to refine the presentation of the architecture. The architecture itself stood up to all challenges.
• Moving Beyond the architecture: After the architecture won approval, created a policy language that allows for fine grained control of when an institutional policy "wins" and when the user's policy does.

This architecture and the policy language are being implemented and rolled out by a major research university as part of its identity and access management infrastructure; the grant organization (NSTIC) is delighted, as is Internet2. You can learn more about CAR here: Internet2 CAR Website

A startup creating a mobile coupon app with reward points and a social networking component was unsure about how to protect customer data from both outsiders and insiders. It was also unclear about how to model an "account" given that a customer could have multiple phones, could change phones, etc. Proposals from the company's own engineers weren't cutting it.

• Fact Finding: Interviewed the director of engineering about their existing client-server design, and what they wanted for the future. Also, reviewed an existing security proposal from an internal engineer.
• Solution Drafting: Created a clear model of users, accounts, and phones. Provided design and implementation recommendations to help enforce the model and protect both client and server resources. The recommendations covered authentication, authorization, cryptographic keys in support of authentication, and life-cycle management of users and keys.
• Documenting & Soliciting Feedback: Detailed the account model, design recommendations and implementation recommendations in a series of emails and phone calls with the director of engineering.