SEMI International Standards
Standards New Activity Report Form (SNARF)
Date Prepared: 12/03/2020Revised (if Applicable):

Document Number: 6719
SNARF for: Revision to SEMI E132-0419: Specification for Equipment Client Authentication and Authorization

Originating Global Technical Committee: Information & Control
Originating TC Chapter: North America
Task Force (TF) in which work is to be carried out: Diagnostic Data Acquisition Task Force NA
Note: If a new task force is needed, also submit a task force organization form (TFOF)

___________________________________________________________________________
1. Rationale:
a. Describe the need or problem addressed by this activity.
(Indicate the customer, what benefits they will receive, and if possible, quantify the impact on the return on investment [ROI] if the Document is implemented.)
There are flaws in the SEMI E132 Document that requires Major Revision of the Standard, such as:

1. In section 2 Scope, it states “It is assumed that the interface specified by this Standard will be operating in an environment where there are no malicious attacks such as inside a closed factory network.” It may be all right if the safe environment can be really assured. However, we need to consider risks of any security problems that may exist in real environment. By that consideration, we need to add caution in the Limitation section that the system might require authentication and/or encryption depending on the environment.

2. In section 3 Limitation, we need to add a limitation “This Standard refers only to the authentication of application processes, and does not support or address authentication of human users.”, that is currently defined in 5.1.5 where is wrong place to state the limitation of the Standard.

3. In section 5 Terminology, it might be hard for the readers to get reasonable meaning form the definitions. For example, “5.1.5 authentication ¯ the process of determining whether a user or process is, in fact, who or what it is declared to be.” may be (or may not be) all right from the language aspect, but not enough to get the idea for the readers. Revision of the definitions is required.

4. Descriptions of the authentication in the SEMI E132 are required be improved.
Something what seems like the details of the authentication method are defined ambiguously in the E132; in Section 8.3.1 and Section 9. Basically, the main standard of E132 is intended to defined the concept, and the details of the implementation should be defined in the subordinate standard as stated in the Limitation. Definition of authentication in E132 should be limited to describe the purpose and the concept of the authentication.

Without the revision of the Document, the readers of E132 might get confused and the readers lose the credibility to the standard.

We need to revise the Standard to make it more reasonable for the readers.


As part of supporting HTTP/2 in the EDA Standards with gRPC and Protocol Buffers, some changes may be required to SEMI E132 to accommodate new better ways of organizing information, and to accommodate no longer using SOAP/XML communications.


Some changes may be required to SEMI E132 to streamline functionality and better reflect actual customer use cases. (For example, distinguishing between Client and Consumer functionality, error handling and SessionPing behavior)


The first part of the SNARF has been previously approved as part of SNARF # 6571 - Revision to SEMI E132: Specification for Equipment Client Authentication and Authorization. This SNARF is proposed due to certain voters claiming proposed changes are out of scope of that SNARF. SEMI Regulations prevent us from revising the existing SNARF with new scope items.

This revision intends to make it clear that every proposed change cannot be predicted, yet still convey the intended changes and magnitude of the changes.



b. Estimate effect on industry.
2: Major effect on an industry sector - identify the relevant sector
Sector or Company Information: Anyone implementing EDA that upgrades to the next version

c. Estimate technical difficulty of the activity.
II: Some Difficulty - Disagreements on known requirements exist but developing consensus is possible

___________________________________________________________________________
2. Scope:
a: Describe the technical areas to be covered or addressed by this Document development activity. For Subordinate Standards, list common concepts or criteria that the Subordinate Standard inherits from the Primary Standard, as well as differences from the Primary Standard:
Major Revision of SEMI E132.
1. Purpose with better descriptions
2. Scope with better description
3. Limitation to add the caution for the security and to clarify the entities to be authenticated.
4. Referenced Standards and Documents to add related RFCs
5. Terminology to improve definitions to provide reasonable meanings to readers.
6. Convention
7. Background
8. Overview with better descriptions
9. Authentication with removing current content to add requirement of authentication to be defined in the Subordinate Standard.
10. Authorization with better descriptions
11. Administration with better descriptions
12. Session Communications with better descriptions
13. State Model with better description
14. Client Interface with better descriptions
15. Interface Discovery with better descriptions
16. Compliance with better descriptions

These changes are intended to improve the readability of the Standard.

Allow changes to support and best leverage HTTP/2 integration with gRPC and Protocol Buffers, and general interface improvement. For example:
- The EstablishSession and EnhancedEstablishSession messages need to be updated to include a ClientID parameter. This is because the ClientID is no longer embedded as part of a SOAP message header, and needs to be explicitly provided to the EDA server.

There are also some changes required to clean up the document from previous revisions. For example,
- Table 41 last row. There is some extra text that does not say anything. The last row says “The number of consecutive”. That does not say or mean anything and should be deleted,(it was accidentally copied from the row above).
- Figure 15 shows the Session Manager interface has ‘EstablishSession2()’, but there’s no corresponding entry in Table 33 – SessionManger Operations. Figure 15 should be updated to remove the line ‘EstablishSession2()’


The ballot will also include any minor editorial changes and technical errors identified during the ballot creation.

The document will also be updated to:
· Integrate Client Session and Consumer Session concepts.
· Define Notification Message and Operational Message concepts and clarify when they will be sent and how errors are handled.
· Removing implementation specific details in the primary standard (for example SOAP/XML)
· Make error handling consistent.

· Improve definition of SessionID, changing Session Endpoints
· Clarify how encryption and authentication can be used
· Clarify SessionPing, InterfaceDiscovery and communication errors
· Add password definition to ACL (New Feature)


As a major revision ballot, this ballot may include other changes to address features or defects raised by task force members during the review and development of the proposed changes listed above and that are desired to be part of EDA Freeze 3. Significant changes in scope still require a SNARF revision in compliance with SEMI regulations.


b: Expected result of activity
Major revision to an existing Standard or Safety Guideline

For a new Subordinate Standard, identify the Primary Standard here:


Modification of an existing part of Standard(s) or Safety Guideline(s) including Appendices, Complementary Files, and Supplementary Materials

For Standards, identify the Standard Subtype below:
Specification

Miscellaneous (describe below):

___________________________________________________________________________
3. Projected Timetable for Completion:

a: General Milestones
a. Activity Start: 11/01/2020b. 1st Draft by: 01/01/2021
c. (Optional) Informational Ballot by: d. Letter Ballot by: 02/01/2021
e. TC Chapter Approval By:04/01/2021

_____________________________________________________________________________
4. Liaisons with other Global Technical Committees/TC Chapters/Subcommittees/TFs:
a.
List SEMI global technical committees, TC Chapters, subcommittees, or task forces in your or other Regions/Locales that should be kept informed regarding the progress of this activity. (Refer to SEMI Standards organization charts and global technical committee charters and scopes as needed.)
I&C Global Technical Committee

b. List any planned Type I Liaisons with external nonprofit organizations (e.g., SDO) that should receive Draft Documents from Standards staff for feedback during this activity and be notified when the Letter Ballot is issued (refer to Procedure Manual § 7):


c. Intercommittee Ballots:
will not be issued

Identify the recipient global technical committee(s):

___________________________________________________________________________
5. Safety Considerations:
The resulting document is expected:
NOT to be a Safety Guideline

NOTE FOR "to be a Safety Guideline": When all safety-related information is removed from the Document, the Document is NOT technically sound and complete - Refer to Section 15.1 of the Regulations for special procedures to be followed.

NOTE FOR "NOT to be a Safety Guideline": When all safety-related information is removed from the Document, the Document is still technically sound and complete.

___________________________________________________________________________
6. Intellectual Property Considerations:
a. For a new Standard or Safety Guideline and for any part to be modified or added in a Revision of published Standards and Safety Guidelines:
patented technology is intended to be included in the proposed Standard(s) or Safety Guideline(s).

If "patented technology is intended to be included in the proposed Standard(s) or Safety Guideline(s) " is selected above, then also check one:
Letter of Intent received

b. For Revision, Reapproval, Reinstatement, or Withdrawal of existing Standard(s) and Safety Guideline(s):
there is previously known material patented technology necessary to use or implement the Standard(s) and Safety Guideline(s)

c. The body of the Document and any Appendices, Complementary Files, Related Information sections, or Various Materials that may or may not be a part of the Document by reference:
the incorporation of Copyrighted Item will NOT be required



NOTE FORthe use of patented technology or the incorporation of Copyrighted Item(s) is NOT required’: If in the course of developing the Document, it is determined that the use of patented technology or Copyrighted Item(s) is necessary for the Document, the provisions of Regulations § 16 must be followed.

NOTE FORwill incorporate Copyrighted Item’: A copyright release letter must be obtained from the copyright owner prior to publication.

___________________________________________________________________________
7. Comments, Special Circumstances:
NON-ASSERTION AGREEMENT (LOA) between SEMI and Asyst Technologies has been signed with for US Patents #11/340101, #11/107508, #09/899833, and 09/496009, in 2008.


The first part of the SNARF has been previously approved as part of SNARF # 6571 - Revision to SEMI E132: Specification for Equipment Client Authentication and Authorization. This SNARF is proposed due to certain voters claiming proposed changes are out of scope of that SNARF. SEMI Regulations prevent us from revising the existing SNARF with new scope items.


__________________________________________________________________________
8. TC Member Review:


Member Review Start Date; 12/11/20
Member Review End Date: 12/25/20

NOTE FOR ‘TC Member Review’ is required by the Regulations for a period of at least two weeks
before approval of a new, or a major revision of an existing, Standard or Safety Guideline. (Refer to Regulations ¶ 8.2.1)
__________________________________________________________________________

9. SNARF Approval Dates:
TC Chapter or GCS01/29/2021
Recorded in TC Minutes

__________________________________________________________________________

10. SNARF Extension Dates:
TC Chapter Extension Granted on
Extension Expires on