Draft minutes TAB meeting 13 June 2018

Action items

- NEW - Chet to use Stefan's email to draft a proposal and circulate / refine it among us that can then be sent on to Scott

- NEW - Chet - revise the sections on announcing vulnerability and circulate back to TAB

- NEW - Chet - update the spec templates with security considerations section and send out an announcement to chairs

- Stefan to get rest of OASIS Standards page data loaded to spreadsheet

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

9) Progress on the editor's manual

10) Progress on Google sheet

11) AOB

Minutes

1) Roll call

Trey Darley
Jacques Durand
Patrick Durusau
Chet Ensign
Stefan Hagen

Invited expert:

Ashok Malhotra

2) Agenda

No discussion of agenda. No objections to approval. Agenda approved.

3) Approve minutes

May 2nd: https://www.oasis-open.org/apps/org/workgroup/tab/email/archives/201805/msg00006.html

May 30th: https://www.oasis-open.org/apps/org/workgroup/tab/email/archives/201805/msg00066.html

No discussion of minutes. No objections to approval. Both minutes approved.

4) Status of public reviews

I misspoke about open PRs. I thought OSLC Requirements Management was open but it is pending.

Discussion about how the OSLC TC is approaching conformance clauses.

5) Status of action items

Stefan to get rest of OASIS Standards page data loaded to spreadsheet.
Ongoing

6) SwaggerHub for OASIS

Reviewed Stefan's feedback on the value proposition.

Patrick notes that depending on how it is managed (e.g. OASIS loads the data versus each TC loading the data) there may be implications to the OASIS IPR protections that have to be considered.

Consensus that this should be written up and submitted to Scott McGrath.

A.I. - Chet to use Stefan's email to draft a proposal and circulate / refine it among us that can then be sent on to Scott

7) Discuss draft incident response plan

Reviewed current draft and discussed notifying MITRE/NIST channels, possibly others. What should the timing be?

A.I. - Chet - revise the sections on announcing to cover the above alternatives and circulate to TAB for review.

8 ) Add Security Considerations to the OASIS spec template

A.I. - Chet - add section to templates and announce to chairs@ mailing list

Trey suggests that in communication to chairs etc. state that OASIS is moving forwards to address security implementations - this is one step - be aware that this will likely evolve over time.

9) Progress on the editor's manual

Tabled to next meeting

10) Progress on Google sheet

Tabled to next meeting

11) AOB

No other business. Meeting adjourned.

Next meeting will be Wednesday, June 27, 2018 at at 16:00 UTC.

=== Chat log ===
Chet: Today's agenda:
Chet: 1) Roll call

2) Approve agenda

3) Approve minutes

May 2nd: https://www.oasis-open.org/apps/org/workgroup/tab/email/archives/201805/msg00006.html

May 30th: https://www.oasis-open.org/apps/org/workgroup/tab/email/archives/201805/msg00066.html

4) Status of public reviews

OSLC Requirements Management Version 2.1. Specification

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

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

Chet:



anonymous morphed into Trey
Chet: Attending: Trey, Patrick, Ashok, Chet, Jacques
Chet: 2. Agenda
Chet: No discussion. No objs. Agenda approved.
Chet: Minutes
Chet: No discussion. No objs. Minutes both approved.
Chet: 4. Public reviews
Chet: PR closes 6/21
Chet: ASking for help on the OSLC PR - conformance clauses missing
Chet: https://lists.oasis-open.org/archives/members/201806/msg00001.html
Patrick: 5.3 Implementation Conformance
5.3.1 Changes to the OSLC Core Vocabulary MUST be approved by the OASIS OSLC Core TC. The OSLC Core Vocabulary is assigned the namespace URI of the http://open-services.net/ns/core#.
5.3.2 Domain TCs and other extensions MUST contribute their vocabulary terms in a namespace which is assigned to them as an authority.
5.3.3 OSLC Core, domain and other extensions SHOULD reuse existing vocabulary terms from stable vocabularies such as [DC-TERMS], RDF [rdf11-concepts], RDF Schema [rdf-schema], [FOAF], [skos-reference] and OSLC. New vocabulary terms should only be created when there is no clear existing choice available. See the [LDP] similar clause on reuse.

See section 10. Terms for details on common property terms.
Chet: 5. Status of AIs
Chet: Stefan noted - still open
Chet: 6 Swaggerhub
Chet: https://lists.oasis-open.org/archives/tab/201806/msg00012.html
Chet: Trey - it is an open standard for describing REST APIs and the site lets you generate code from that
Chet: python, ruby, etc
Chet: What steps would OASIS take? Trey - for TCs that have a RESTful component similar to TAXII 2, they could publish in Swaggerform API and present to OASIS to load to its corporate account
Chet: Any reason not to do that? Trey - well, the future is dangerous territory - but given that O is trying to be more agile & move in the implemetation marketplace, this would be a low cost / low risk trial run
Chet: Patrick: if O sets up its own SH account and then members bring APIs to be loaded on to it, that is one thing. Then SH is basically a publication channel. Also, O would need to maintain it there in perputuity. If the account is for O to set up the account but then open it to all, that might be a more diffcult to monitor facility.
Chet: Trey - the data format under Swagger is open so if the *service* proved a problem, we could find other ways to host the service.
Chet: Trey - in so far as we rely on external services like Github, SH would be the same kind of situation
Trey: Hi, Stefan _
Chet: Stefan joins
Chet: Patrick - we just need to ensure that it is handled in a way that is subject to the OASIS IPR rules
Stefan Hagen: It is about publication into a playground like service - so people can get a grip on OASIS standards
Chet: Jacques - probably not much different from any other 3rd party tooling that O would use. Whoever puts content on the platform has to abide by the IPR rules that apply
Trey: It feels like we're spending a lot of time debating a relative non-issue wrt SwaggerHub. Are we going to discuss the draft vulnerability disclosure process? That should be a much higher priority.
Chet: Yep - we will move this along
Patrick: I see a difference between a Swaggerhub account for OASIS, used for publication of APIs and a Swaggerhub account by OASIS and used by OASIS members making IPR contributions. How are the latter governed by the OASIS IPR agreement.
Chet: A.I. - Chet to use Stefan's email to draft a proposal and circulate / refine it among us that can then be sent on to Scott
Chet: 7. Incident response plan
Patrick: Trey you should suggest to Jamie Clark that IPR is a non-issue wrt TC member contributions. I'll be interested in hearing his response.
Chet: https://docs.google.com/document/d/1xoBVeo6MOgypEB3iWY48MHfEuzk7lV9A0eWaBja9klk/edit
Trey: @Patrick: I'm *not* saying that IPR is a non-issue wrt TC member contributions to SwaggerHub. I *am* suggesting that the CLA be adapted to cover IPR for TC member contributions to SwaggerHub.
Chet: discussion about notifying the MITRE/NIST channels
Chet: add that to the draft
Chet: once we make the announcement public
Chet: Trey - 2 scenarios. 1 - researcher discovers an exploitable vulnerability and they want to talk about it at BlackHat 6 weeks from now and isn't willing to hold off. In that case, it appears resonsible to announce in advance to those orgs so that people are aware before it gets the high profile announcement.
Chet: 2. case where a broader issue is announced that has a ripple affect to oasis standard that can't be migitated quickly
Chet: so - 1) mitigation in private then announce but cases where 2) announcement to the large channels (MITRE/NIST/etc.) where the hackers are going to find out before it is mitigated anyway
Chet: A.I. - Chet - revise the sections on announcing to cover the above alternatives.
Chet: Trey - thinks of it this way. Ford Focus has some kind of flaw. If it is a few VIN #'s then they can reach out. But if it is everybody, they can't keep it narrow.
Chet: Chet will ping the TAB mailing list after making the changes for another read
Chet: J: this may not be just security or should we consider other unexpected limitations? C: this is really focused on flaws that could be exploited for nefarious purposes - not just for general bugs.
Chet: J: it could be broader than that. T: bugs are really a separate issue - non-exploitable bugs can be discussed in the open
Chet: T: broader question of some means to register implementations with OASIS and TCs
Chet: 8. Security Considerations section on spec template
Chet: T: what is there is a good starting point - but high likelihood that guidance to TCs will have to evolve over the next 6 to 18 months
Chet: T: but go ahead and send it out.
Chet: A.I. - update the spec templates and send out an announcement
Ashok: Sorry! Gotta go!
Stefan Hagen: @chet: Please send me the security considerations portion - as we are currently finalising DSS Core v2 and maybe we can already use it
Chet: T: suggest that in communication to chairs etc. state that OASIS is moving forwards to address security implementations - this is one step - be aware that this will likely evolve over time.
Chet: @stefan - right after this
Sent transcript to: chet.ensign@oasis-open.org

20180613 (last edited 2018-06-23 20:01:21 by chet.ensign)