DTF Web App Documentation
For a how-to on setup and deployment, refer to setup wiki. See bottom of this page for screenshot of working application for reference.
You must login to this app using an OpenID Connect Provider (OP). For a full locally hosted setup, you can deploy your own OP using the mitreid-connect reference implementation.
The content of the initial cards state is based on the modularized trust framework document here: https://github.com/mitreid-connect/trust-framework/blob/master/TrustFramework.md
Our data model for trust framework components is exemplified in the JSON file card.json
Figure 1. Visual diagram of trust framework card data model.
The previously mentioned trust framework was chunked into the discrete cards that are set up in the built-in in-memory hsql database of this application. Cards can only be connected to one another if a card provides all of the tags for the dependency slot it is trying to fit in (Figure 1).
Figure 2. Partial model of demonstration dynamic trust framework content.
The root card of this scenario, the "Trust Framework Rules Envelope" card, has several dependency slots, including Roles, White List, Black List, Grey List, and Record Keeping and Logging
Each of these slots can be fulfilled with cards providing their required dependencies, in this case, the Roles, White List Policy, Black List Policy, Grey List Policy, and Record Keeping & Logging cards. These cards in turn may have their own dependency slots that require additional cards to fulfill this instance of a trust framework. An example is the Identity Provider dependency slot of the Roles card. There are two cards in the system that can be used in this slot: id.mitre.org card or the oidc.mit.edu card.
A few loose ends are intentionally left in the system as an exercise to the user to learn how to use this card system. These are the User Authority, Policy Authority, and Relying Party dependencies in the Roles card and System Operator dependency in the White List Policy card and Black List Policy card. To complete this exercise, click Create New Card, and edit the card to your liking. Choose the appropriate Tag in the Provides section and click Save Card. Now this card should be available to choose in the respective dependency slot.
Below is a screenshot of the webapp with a partially completed instance of this dynamic trust framework. This collection of cards follows the demonstration scenario described above. Cards that do not have any dependencies are considered leaf nodes of a dynamic trust framework instance. Once all dependency slots have been filled by cards and only leaf cards remain, then this trust framework instance is complete.
Figure 3. Screenshot of dynamic trust framework instance builder.