TAB conference call

When:  May 30, 2018 from 16:00 to 17:00 (UTC)
Associated with  Technical Advisory Board (TAB)
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: