TIER-Data Structures and APIs Working Group Home

Subgroup 1 : Wednesday, 20 April , 2016 at 3 pm Eastern, Noon Pacific, 8 pm UTC
- video: https://bluejeans.com/439600784/browser
Subgroup 2: Friday, 22 April , 2016 at 10 am Eastern, 7 am Pacific, 3 pm UTC
- video: https://bluejeans.com/965988291/browser

Attendees are encouraged to participate in live-scribing the meetings on the above Google doc.

Working Group Chair: Keith Hazelton, University of Wisconsin

Help education and research organizations solve the Identity and Access Management (IAM) challenges they encounter
- By providing open source implementations of key IAM capabilities and assuring their long-term sustainability
- By standardizing
  - How applications (whether local, federated or SaaS) integrate with IAM infrastructure
  - How existing institutional IAM infrastructure can interoperate with TIER components to provide a full IAM service suite

Expose IAM capabilities at RESTful endpoints
- ...Where it makes sense: LDAP, SAML, etc. still have their well-earned place, TIER will take full advantage of such common protocols and interfaces. OAuth 2, OpenID Connect and UMA are also coming into play.
- REST ness in the TIER context means: HTTP verbs operate on Resources (groups, users,....); RPCish idioms should only be used when nothing else will do what needs to be done.
- The model for interoperating with existing institutional IAM services is to provide the TIER components with connectors that know how to interact with both back end legacy systems as well as the growing number of contracted-out SaaS and PaaS services
- An API-first design helps us achieve and maintain a level of abstraction from specific implementation choices. This gives TIER adopter sites the option to wrap their favorite legacy IAM service in a TIER API knowing that it will integrate well with other TIER or TIER-compliant packages.
Adopt the many useful conventions specified in the new IETF standard, SCIM 2.0 ,
- around the design choices that would otherwise tend to provoke endless working group debates on matters such as pagination, metadata schema, data formats, etc.
- the choice to leverage SCIM, as much as anything else, made the decision to support JSON easier. Support for XML can be provided if and where it's needed.

The canonical specification language for HTTP-oriented APIs in TIER is Swagger 2.0
Why Swagger and not RAML or API Blueprint? (see this recent comparison on dzone)
- In the move from version 1 to version 2, Swagger incorporated a lot of RAML's best features (around reusable definitions, etc.)
- Swagger 2 has been adopted as the basis for further development by the industry-launched Open API Initiative (http://openapis.org, more on github here) and that should strengthen the already thriving Swagger developer and adopter community

By April 2016

Publish and promote the adoption of a first-round set of conventions for API and data structure design. The goal is to inform and hopefully influence API development for Release 1.0 Grouper and COmanage components.
Pair the basic group and membership management APIs with an event-driven messaging approach to the same functionality. Clarify the circumstances that favor one approach over the other.
Assess possible models for APIs and data structures around consent.
Document the first round requirements for administering and monitoring IAM infrastructure and specify the kinds of instrumentation needed in each component to support administration and monitoring.