...
- Collect use cases. Identity empowers enterprise needs, so these should be general use cases. They are typically delivered by the main service validation group, though the identity group may ask for clarifications or changes and might need to interpret the text. They may come from the service("this is what we offer") or from the schools("this is what we need") or both.
- Assess current implementation and roadmap. We compare the current implementation to the main NET+ Identity Guidance for Services. This gives us a basis for conversation, architecture, and prioritization. This may happen in parallel with the gathering of use cases in step 1.
- Compare implementation, roadmap, and use cases. Use cases collected in step 1 are compared against functionality collected in step 2, and any additional specific identity implementation requirements that are identified in step 2, such as metadata usage, are injected.
- Prioritize implementation and refine roadmap. High, low, or blocker priority may be assigned to discrepancies identified in step 3. The difficulty of implementation may be considered as well.
- Implement and document. Build it and write about it. This will typically involve joining InCommon and doing some implementation work. Example documentation Documentation outcomes are discussed with examples below.
- Schools sign off. The schools are the ultimate arbiters of whether the implementation meets the needs of the program and whether and how the service should be accepted.
- Iterate. New requirements or opportunities emerge frequently, so the above process may be performed recursively, preferably in short order and small bites.
...