You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document is essentially an interoperability profile - it does not define any new mechanism, rather tells implementers how to combine specifications to achieve certain use-cases in the EDU space and provides guidance when there are optionality/extensibility points in those specifications.
I have not found such but if there are places where an entirely new mechanism in the tech stack is invented, it would be clean to externalize that mechanism into a separate document and put a reference to it from this current document, after renaming this current document to a "profile"
The text was updated successfully, but these errors were encountered:
New/breaking changes would be documented under a newly versioned specification document. The document format is part of a greater set of consistent 1EdTech patterns and the naming is accurate.
it does not define any new mechanism
I'm unclear why you feel this is the case. While VCs themselves are a separate spec being leveraged here, the specifics of the data payloads for valid open badges is specified here. As are the federated backpack APIs.
This document is essentially an interoperability profile - it does not define any new mechanism, rather tells implementers how to combine specifications to achieve certain use-cases in the EDU space and provides guidance when there are optionality/extensibility points in those specifications.
I have not found such but if there are places where an entirely new mechanism in the tech stack is invented, it would be clean to externalize that mechanism into a separate document and put a reference to it from this current document, after renaming this current document to a "profile"
The text was updated successfully, but these errors were encountered: