The picture shown conveys the Consumers on the left supply data through requests to the ODS in the middle which can then handle queries from the Consumers on the right.  While these are artificial limits, it helps convey how an ODS can help create a Unity Ecosystem by taking on the burdens of being the only provider.  When it comes to growth, notice that the right half of this example is exactly the same as our direct solution.  At the same time, you can see that if the two Consumers on the left-hand side became providers and the ODS was swapped out with a Broker, we would have a Brokered Solution, albeit not as large as the previous.

Hybrid Solutions

Having a common REST API and supporting services opens the door to many possibilities.  When putting together solutions, one shouldn’t be afraid to mix and match approaches in order to construct the best solutions possible.  Here is what it might look like to combine all the functionality discussed above.

Here we have an ODS that can store whatever data isn’t provided elsewhere, linked by a Broker managing the integration, and a Direct Provider hosting additional Consumers.  While an integration like this one is best rolled out in phases, growing to this level of sophistication is a very real possibility.  In fact, many projects, both here and abroad, have used brokers as Infrastructure Providers in front of one or more Data Providers to create a more modular Data Hub.

Conclusions

When looking to enter a Unity Ecosystem there is one clear place to start and that is creating a solid Consumer.  Not only is this the least amount of work, the Ecosystems you encounter may very well already have other systems providing data so you shouldn’t assume this will be one of the roles your software will fulfill.  In such a Unity Ecosystem, your Consumer may contribute to the data by making create, update, and delete requests.  If it becomes necessary to beef up your Adaptor in order to fulfill the role of a Provider, you will be in a much better position to understand what that will take and what features are important for you to support.

Proposed Changes to the Unity Product Standard 

There is no denying that the transition to the Unity Specification in North America is rapidly becoming a reality.  Because of this, the Policy & Procedures group is looking to update the requirements around SIF Certification. 

As part of this work they are proposing the following. 

• Consumers will not be required to create their own environment, but the call will still be supported.
•  Changes Since support will be expected of all providers.
•  Unlevel the Transport Layer Security (TLS) to version 1.2.
•  Certificates exchanged to verify identity employ a key length of at least 2048bits.
•  All certificates employed must be current.
•  All valid certificates will be accepted.
•  Hostname and certificate mismatches are allowed.
•  All encrypted connections employ a cypher with a minimum key length of 128bits.
• Keep:  HTTP 1.1, XML 1.0, UTF-8, XPath 2.0, XQuery 1.0, XSDs, Gzip,& UUIDs
•  Authentication (pick at least one):  SIF_HMACSHA256 or OAuth 2.0 /w Bearer Tokens
•  Those using JSON will need to use PESC JSON.

Notes:

1. We have one report that Gzip is not currently working with the Test Harness.
2.  For testing our Bearer Tokens do not currently expire.

The current SIF Specification Product Standards can be found here: https://www.a4l.org/page/SIFCertification

Please provide any feedback or comments by February 14, 2020 to John Lovell, Technology Director.

Announcement to Membership: 2020 North American Elections

The Access 4 Learning (A4L) Community has continued to have phenomenal leadership over the past year.  The leadership, guidance and overall dedication to the Community prove critical to our collective successes. With the upcoming Annual Meeting, it is hard to believe that it is time for elections again!  Nominations for the North American Management Board and At-Large Technical Board will be available from January 15 - February 12, 2020 (inclusive).
 
The Management Board is elected for two-year terms.  This year there will be five (5) seats open for the Management Board.  To be eligible to run for the Management Board, the individuals shall be at least eighteen (18) years old and be A4L Community Voting Participants or employed by or representing an A4L Community Voting Participant and duly authorized to represent that A4L Community Voting Participant, but need not be residents of the District of Columbia.  An A4L Community Voting Participant Member institution (including associated subsidiaries of an A4L Community Voting Participant) may have at most one representative on the Management Board at one time.

The At-Large Technical Board is elected for a one-year term.  There are four (4) seats open for the At-Large Technical Board members.  At-Large Technical Board members must be A4L Community Voting Participants or employed by or represent an A4L Community Voting Participant and duly authorized to represent that A4L Community Voting Participant.

You can download the policies and procedures for the Annual Elections as outlined by the Elections Committee on the A4L Community Site here (login required).

For the 2020 A4L Community North American Annual Election process, the following dates apply:

• December 17, 2020: Announcement to membership that elections will occur
• January 15, 2020: Nominations open
• February 12, 2020: Nominations close
• by February 19, 2020: Elections Committee convenes to confirm ballot
• February 25, 2020: Ballot released
• March 10, 2020: Voting closes at 5:00 pm Eastern
• March 11, 2020: Elections Committee convenes to confirm results
• March 18, 2020: Elections results announced during the Interoperability & Privacy Symposium

We will use a virtual election tool and all nominations must be submitted electronically.  The Primary Business Contact will be the official vote for each A4L Community Voting Participant, unless a designee is provided.  Please contact Penny Murray, to confirm your Primary Business Contact, or organization ‘designee’ for the 2020 NA Elections.

We will send out information to submit your nomination beginning on January 15, 2020.  Please consider nominating yourself, asking someone to nominate you or nominate someone else to run for one of these leadership positions within the A4L Community!

The Global Education Privacy Standard – or GEPS – is finally a reality and ready for prime time! 

The tool aligns contract clauses with technical obligations to meet those clauses and then allows you to map those obligations to control benchmarks from any source (IEEE, ISO, NIST, etc.) to create a machine readable XML Privacy Obligations Document (POD). The POD can accompany a contract between end user and vendor. 

What does that mean for you? 

If you are an end user it means you can instantly communicate the critical privacy expectations with your vendors beyond normal contract terms in an automated way.  Vendors benefit by getting enough information in the POD to deliver on the expectations of their customers and then be able to validate they fulfil their part in privacy stewardship. 

To find out more, please visit: https://privacy.a4l.org/geps/

'Unity’ Specification enters Community Review

The Access 4 Learning (A4L) Community, is now proud to cause a new “buzz” – the best of the best from 20 years of interoperability specifications to address school needs and allow for states and vendors to implement the US Department of Education’s Common Education Data Standards (CEDS).  The new Specification – code named “Unity” – is built using 20 years of experience by our more than 3,000 volunteer members developed using open, non-proprietary and transparent processes linked to a quality control Certification Program.  It contains the most comprehensive K12 data model and modern transport technologies to securely move the data to provide it to the right person at the right time in the right way under local data privacy policies.

The North American Technical Board (NATB) has set out to provide the market with an incremental path forward… and the recipe is simple!.  This draft Specification includes data objects from the (NA) 2.8 Data Model; xPress Roster objects; IEP objects; Address and Student Program Association objects; Support of UUIDs and legacy GUIDs; Pluggable Code Sets & Extension Points throughout; and CEDS Mapping.

The Community Review is currently slated to run from March 28 – April 14, 2019 (inclusive).  ALL North American Community Members are encouraged to provide their approval/feedback before COB on April 14 and will need to login to the website to access the survey here.