OASIS

The OSLC PROMCODE TC defines technical elements and guidelines for project management of Software Supply Chains. The OSLC PROMCODE TC will examine the work done by the PROMCODE consortium on exchanging project management information, and will modify/extend the work so that it fits the needs of the global community.
 
The OSLC PROMCODE TC will work to:

1. Define a model of project management information for SSC. A model should describe a minimum set of information and relationships commonly used by carriers and suppliers to manage software delivery.
2. Define a set of resources and their relationships following the OSLC framework as defined by the OSLC Core TC.
3. Create additional technical elements as required to support current and future scenarios for OSLC User Groups, OSLC MS-affiliated TCs, Subcommittees and the OSLC Member Section Steering Committee.
4. Leverage existing work, such as existing OSLC specifications, as much as possible. If gaps are identified, the OSLC PROMCODE TC will attempt to resolve them with other affiliated TCs prior to defining new concepts within PROMCODE.

The PROMCODE (Project Management of Contracted Delivery for Software Supply Chains) specifications advance a standard for exchanging project management information across organizational boundaries in support of Software Supply Chain (SSC) delivery. PROMCODE leverages other OSLC specifications which apply World Wide Web and Linked Data principles to enable products, services and other distributed network resources to interoperate successfully. TC members intend to request affiliation with the OASIS OSLC Member Section.
 
This TC is part of the OASIS OSLC Member Section. For more information on the OSLC PROMCODE TC, see the TC Charter.

The OASIS PKCS 11 Technical Committee develops enhancements to improve the PKCS #11 standard for ease of use in code libraries, open source applications, wrappers, and enterprise/COTS products: implementation guidelines, usage tutorials, test scenarios and test suites, interoperability testing, coordination of functional testing, development of conformance profiles, and providing reference implementations.
 
The updated standard provides additional support for mobile and cloud computing use cases: for distributed/federated applications involving key management functions (key generation, distribution, translation, escrow, re-keying); session-based models; virtual devices and virtual keystores; evolving wireless/sensor applications using near field communication (NFC), RFID, Bluetooth, and Wi-Fi.
 
TC members are also designing new mechanisms for API instrumentation, suitable for use in prototyping, profiling, and testing in resource-constrained application environments. These updates enable support for easy integration of PKCS #11 with other cryptographic key management system (CKMS) standards, including a broader range of cryptographic algorithms and CKMS cryptographic service models.

The OASIS PMRM TC works to provide a standards-based framework that will help business process engineers, IT analysts, architects, and developers implement privacy and security policies in their operations. PMRM picks up where broad privacy policies leave off. Most policies describe fair information practices and principles but offer little insight into actual implementation. PMRM provides a guideline or template for developing operational solutions to privacy issues. It also serves as an analytical tool for assessing the completeness of proposed solutions and as the basis for establishing categories and groupings of privacy management controls.

The purpose of the OASIS Production Planning and Scheduling TC is to develop common object models and corresponding XML schemas for production planning and scheduling software, which can communicate with each other in order to establish collaborative planning and scheduling on intra and/or inter enterprises in manufacturing industries.

SARIF TC members are developing an interoperability standard for detecting software defects and vulnerabilities. The goal is to define a common output format for static analysis tools that will make it feasible for developers and teams to view, understand, interact with, and manage the results produced by all their tools.
 
SARIF represents a leap forward in the usability of static analysis tools. Many organizations in the safety and security communities use several competing tools on their code. SARIF will allow them to combine and compare the results more easily to gain a sharper picture of the issues in their code that need to be addressed. Engineering teams will be able to easily access a broad range of potential defects and vulnerabilities in compliance with privacy and accessibility standards. SARIF will support the development of products whose code spans languages and operating systems.

The OASIS Litigant Portal (LP) Technical Committee is chartered to produce specifications for data interoperation between Litigant Portal Modules. The technical specifications are collectively referred to as the Litigant Portal Exchange (LPX) Specifications. Portal modules are designed to provide assististance to self-represented litigants. The modules will (a) define structured interactions between related modules in the portal, (b) facilitate navigation between modules in the portal, (c) define interfaces with external partners and resources. Specifications for information exchange will initially support XML data formats. Members of the LP TC may also produce non-Standards Track content such as tutorials, usage guides, quick start guides and other documents that will assist the broader community in adopting the LPX specifications.
 
The TC is affiliated with the OASIS LegalXML Member Section. For more information on the LP TC, see the TC Charter.

The SOA Repository Artifact Model and Protocol (S-RAMP) TC defines a common data model for SOA repositories as well as an interaction protocol to facilitate the use of common tooling and sharing of data. The TC will define an ATOM binding which documents the syntax for interaction with a compliant repository for create, read, update, delete and query operations.

The OASIS Service Oriented Architecture Reference Model TC develops a reference model to encourage the continued growth of different and specialized SOA implementations whilst preserving a common layer of understanding about what SOA is.
 
The TC will:
 
-- deliver a Service Oriented Architecture Reference Model (SOA-RM) and, if it elects, ancillary materials as described under "purpose" above.
 
-- allow the commission of sub-committees to create specialized SOA models for vertical industries or technology families.
 
-- propose usage and implementation guidelines for creating specializations of the reference model, whether as a formal methodology or as best practice guidelines.

SOA End-to-End Resource Planning is a technology that optimizes deployment of services onto a SOA description of an application. The focus in EERP is on the characterization of the business characteristics of a service (called Business Quality of Service in the references listed under External Resources below), characterization and accessing the reputation of potential service providers, and Business Service-Level Agreements. See the EERP white paper approved by the committee for details and future direction.
 
The SOA-EERP Technical Committee will focus on enablers for optimization. The enablers are, for example, definitions of the framework for representing the business process service rating terms, such how to represent cost, time, value, etc. We define "optimization" as maximizing business value by enabling improved real-life eBusiness process and resource planning at both design time and run time. In particular,

• Resources are services performed by people, machines, and hardware/software applications, and represented by SOA services. Defining the qualities of such a business service will be done with metrics expressed as Business Quality of Service (BQoS). The nature of BQoS varies across industries and services.
• Business processes are optimized in order to reduce cost, improve efficiency, and otherwise improve business results. Extensions to Business Process Management Notation and execution environments such as WS-BPEL will facilitate process improvement through automatic optimization and evolution.

The Security Assertion Markup Language (SAML), developed by the Security Services Technical Committee of OASIS, is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application.
 
If you are a manager looking for a high-level overview of SAML, the Executive Overview is recommended. If you are looking for a technical introduction to SAML concepts and capabilities, it is recommended to start with the Technical Overview. Additional technical information, including the complete set of SAML specifications, can be found in the knowledgebase at saml.xml.org.

MQTTisa Client Server publish/subscribe messaging transport protocol. It is light weight, open, simple, and designed to be easy to implement. These characteristics make it ideal for use in many situations, including constrained environments such as for communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts where a small code footprint is required and/or network bandwidth is at a premium.

The XACML architecture promotes a loose coupling between the component that enforces decisions, the policy enforcement point (PEP), and the component that decides based on XACML policies, the policy decision point (PDP). The XACML standard defines the format of the request and the response between thePEP and the PDP. As the default representation of XACML is XML and is backed by a schema, the request and response 8are typically expressed as XML elements or documents. With the rise in popularity of APIs and its consumerization, it becomes important for XACML to be easily understood in order to increase the likelihood it will be adopted. This profile aims at defining a JSON format for the XACML request and response. It also defines the transport between client (PEP) and service (PDP).