Creating A Consent System

The Challenge
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.

In this particular case, I already knew a lot about the identity management stores, policies, and procedures in higher education, so I could get to work on a solution without interviewing subject matter experts. Here are the steps I took:

  • Fact Finding: Reviewed the characteristics of existing consent systems, particularly one that had modest traction in higher education. Assessed what was working well, and also not so well.
  • Architecture Drafting: Considered what could be a better fit in terms of functionality -- one 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

Simplifying Administration Of Identity

The Challenge
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.

Security For A Mobile Phone App With A Social Networking Component

The Challenge
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.

“Marlena was exactly what we needed during the initial development of our service and mobile application. She asked a lot of penetrating questions, forced us to confront some of our assumptions, and led us to a much more secure product.” - Andy Affleck Director of Engineering, Ozmott LLC

Engagement period: 10 hours.