-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Addition of Protective Marking sub-section to api-security.md #49
Addition of Protective Marking sub-section to api-security.md #49
Conversation
…ussed Working Group July 27 Addition of Protected Marking sub-section to API Security, as discussed Working Group July 27
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with these changes from a Victorian Government API standards viewpoint. We are comfortable to implement the protective marking approach with the APIs we build in the WoVG API Team that contain sensitive data.
That said, the bullet points in the 2nd paragraph have slightly gone out of alignment, can you resolve and resubmit?
Updated as requested |
To be replaced with generalised version, based on current v1.1 |
Addition of Protective Marking sub-section to API Security, as discussed Working Group July 27.
A unified approach to protective marking would greatly enhance API inter-operabilty. It is acknowledged that each jurisdiction may have similar requirements, and this section should be open to evolution.
I have based this addition on Peeyush's PR update to this document.