Description:
Topic: OASIS TAB fortnightly call
Times: Fortnightly on Wednesdays at 16h00 UTC
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/217315360
Or iPhone one-tap :
US: +16465588656,,217315360#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
Belgium: +32 (0) 2 588 4188
Canada: +1 647 558 0588
US: +1 646 558 8656 or +1 669 900 6833
Luxembourg: +352 2786 1188
Netherlands: +31 (0) 20 241 0288
Germany: +49 (0) 30 3080 6188
United Kingdom: +44 (0) 20 3695 0088
Australia: +61 (0) 2 8015 2088
France: +33 (0) 1 8288 0188
Japan: +81 (0) 3 4578 1488
New Zealand: +64 (0) 4 831 8959 or +64 (0) 9 801 1188
Meeting ID: 217 315 360
International numbers available: https://zoom.us/zoomconference?m=Ah-hy2Oh7sBJE9MS83I3HwyP16LyBRzp
==========
Agenda:
=== Agenda ===
1) Roll call
2) Approve agenda
3) Approve minutes
4) Status of public reviews
Exchange Header Envelope (XHE) V1.0 from BDXR TC, end
5) Status of action items
- Stefan to get rest of OASIS Standards page data loaded to spreadsheet
- Chet to ask Frederick for any copies of information on the security concerns section of W3C specifications
- Chet set up the document in Google Docs and we can craft it into an incident response
6) SwaggerHub for OASIS
7) Discuss draft incident response plan
8) Add Security Considerations to the OASIS spec template
9) Progress on the editor's manual
10) Progress on Google sheet
11) AOB
==========
Minutes:
=== Action items ===
- Stefan to get rest of OASIS Standards page data loaded to spreadsheet
- Chet to ask Frederick for any copies of information on the security concerns section of W3C specifications
- Chet set up the document in Google Docs and we can craft it into an incident response
- (NEW) Chet to share incident response plan with Frederick Hirsch and Bruce Rich for comment
=== Agenda ===
1) Roll call
2) Approve agenda
3) Approve minutes
4) Status of public reviews
5) Status of action items
6) SwaggerHub for OASIS
7) Discuss draft incident response plan
8) Add Security Considerations to the OASIS spec template
9) Progress on the editor's manual
10) Progress on Google sheet
11) AOB
=== Minutes ===
1. Roll call
Patrick Durusau
Chet Ensign
Stefan Hagen, Trey Darley - regrets
Invited expert:
Ashok Malhotra
Meeting did not achieve quorum. Discussion only.
2. Approve agenda
N/A
3) Approve minutes
N/A
4) Status of public reviews
Patrick provided TAB comments to BDXR TC on Exchange Header Envelope (XHE) V1.0 from BDXR TC
No upcoming first public reviews in the queue
5) Status of action items
- Stefan to get rest of OASIS Standards page data loaded to spreadsheet
Ongoing. Stefan has provided a new spread sheet with significantly increased records
- Chet to ask Frederick for any copies of information on the security concerns section of W3C specifications
Closed
- Chet set up the document in Google Docs and we can craft it into an incident response
Closed
6) SwaggerHub for OASIS
Discussed what we know. Identified questions that should be considered:
Question: has OASIS gotten any demand for this before?
Question: what would it cost OASIS (both $$ and staff time)?
Question: does Apache / W3C / etc. use this?
Question: what's the appeal? What are its benefits? (e.g. is it where the world goes to look for APIs?)
Question: are there other similar tools that others would prefer?
Further discussion tabled to next meeting.
7) Discuss draft incident response plan
Thanks to Ashok for editorial comments.
Consensus - Frederick Hirsch and Bruce Rich on OASIS board both have experience and interest in the topic. Pass the draft along to them for initial reactions. Respond to comments and then consider by email approving to send to process committee.
8) Add Security Considerations to the OASIS spec template
Reviewed text. Tabled until next meeting.
9) Progress on the editor's manual
No progress this past week. Tabled until next meeting.
10) Progress on Google sheet
Stefan sent new spread sheet with more records. Tabled until next meeting.
11) AOB
No other business raised. Meeting adjourned.
Next meeting will be Wednesday, June 13, 2018 at at 16:00 UTC.
Minutes submitted 31 May 2018 by Chet Ensign.
== Chat log ==
1) Roll call
2) Approve agenda
3) Approve minutes
4) Status of public reviews
Exchange Header Envelope (XHE) V1.0 from BDXR TC, end
5) Status of action items
- Stefan to get rest of OASIS Standards page data loaded to the spreadsheet
- Chet to ask Frederick for any copies of information on the security concerns section of W3C specifications
- Chet set up the document in Google Docs and we can craft it into an incident response
6) SwaggerHub for OASIS
7) Discuss draft incident response plan
Add Security Considerations to the OASIS spec template
9) Progress on the editor's manual
10) Progress on Google sheet
11) AOB
anonymous morphed into Ashok
anonymous morphed into Patrick
Chet: Attending: Ashok, Chet, Patrick - regrets: Trey, Stefan
Chet: No quorum yet
Chet: Discussion only
Chet: 4) Public reviews - Patrick sent comments to the BDXR TC
Chet: Ashok - what was the issue with the schema? Patrick - they gave the same schema name to both the annotated and unannotated versions
Chet: A: what was the idea behind the schema visualization tool? P: it would be easier to see what they were trying to do in their schema design.
Chet: P: BaseX has a variety of views you can use
Chet: P: may be able to script something where you toss the schema to BaseX and get a rendered view
Chet: No new first PRs coming up right now
Chet: 5) Status items
Chet: - Stefan to get rest of OASIS Standards page data loaded to the spreadsheet
Chet: Still in progress
Chet: - Chet to ask Frederick for any copies of information on the security concerns section of W3C specifications
Chet: Closed
Chet: - Chet set up the document in Google Docs and we can craft it into an incident response
Chet: Closed
Chet: 6) SwaggerHub for OASIS
Chet: P: it is a json files for describing APIs. how much machinery do you need?
Chet: P: we should find out if people use this? it wouldn't make sense for OASIS to pay for it if it is not going to be used.
Chet: Question: has OASIS gotten any demand for this?
Chet: Question: what would it cost?
Chet: Question: does Apache / W3C / etc. use this?
Chet: Question: what's the appeal? What are its benefits? (e.g. is it where the world goes to look for APIs?)
Chet: Re cost - both $$ and staff time
Chet: P: it is based on the OpenAPI specification - so unlikely to be the only tool out there. Are there other tools that others would prefer?
Chet: With these questions - table the discussion to the next meeting.
Chet: 7) Discuss draft incident response plan
Chet: Thanks to Ashok for the comments.
Chet: https://docs.google.com/document/d/1xoBVeo6MOgypEB3iWY48MHfEuzk7lV9A0eWaBja9klk/edit#
Chet: Consensus - let's pass this along to Frederick and Bruce for their initial reactions.
Chet: P: at some point, the record of the working group needs to go public
Chet: P: how does someone know who to report it to? should OASIS have a general vulnerability email list with a PGP key attached to it - if you don't know who to contact, use this key to encrypt your report and send it here.
Chet: A: put a link to it on every OASIS TC page or specification?
Chet: Next steps:
Chet: - send to F/B for feedback
Chet: - incorporate comments / call for objections to forwarding as a TAB working draft to the BPC
Chet: Add Security Considerations to the OASIS spec template
Chet: A: looks ok
Chet: Here is the text:
Chet: OASIS strongly recommends that Technical Committees consider issues that could affect security when implementing their specification and document them for implementers and adopters.
While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involved communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [RFC3552] lists eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.
In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks
We encourage editors and TC members concerned with this subject to read Guidelines for Writing RFC Text on Security Considerations, IETF [RFC3552], for more information.
Chet: Table discussion to next meeting
==========
Attendance: