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

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 spreadsheet 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 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

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 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

20180530 (last edited 2018-05-31 14:22:11 by chet.ensign)