Standard

The SAML V2.0 metadata specification [SAML2Meta] defines an XML schema and a set of basic processing rules intended to facilitate the implementation and deployment of SAML profiles, and generallyany profile or specification involving SAML. Practical experience has shown that the most complex aspects of implementing most SAML profiles, and obtaining interoperability between such implementations, are in the areas of provisioning federated relationships between deployments, and establishing the validity of cryptographic signatures and handshakes. Because the metadata specification was largely intended to solve those exact problems, additional profiling is needed to improve and clarify the use of metadata in addressing those aspects of deployment. The purpose of this profile is to guarantee that in a correct implementation, all security considerations not deriving from the particular cryptography used (i.e., algorithm strength, key sizes) can be isolated to metadata exchange and acceptance, and not affect the runtime processing of messages.

The TOSCA Simple Profile in YAML specifies a rendering of TOSCA which aims to provide a more accessible syntax aswell as a more concise and incremental expressiveness of the TOSCA DSL in order to minimize the learning curve and speed the adoption of the use of TOSCA to portably describe cloud applications. This proposal describes a YAML rendering for TOSCA. YAML is a human friendly data serialization standard (http://yaml.org/) with a syntax much easier to read and edit than XML. As there are a number of DSLs encoded in YAML, a YAML encoding of the TOSCA DSL makes TOSCA more accessible by these communities.This proposal prescribes an isomorphic rendering in YAML of a subset of the TOSCA v1.0 XML specification ensuring that TOSCA semantics are preserved and can be transformed from XML to YAML or from YAML to XML. Additionally, in order to streamline the expression of TOSCA semantics, the YAML rendering is sought to be more concise and compact through the use of the YAML syntax.

This specification defines a profile for the use of the OASIS eXtensible Access Control Markup Language (XACML), versions 3.0 [XACMLv3]and earlier. Use of this profile requires no changes or extensions to the XACMLstandard. This specification assumes the reader is somewhat familiar with XACML. XACML can be used for controlling access within a single application.This removes hard-coded security constraints from the application code, making it easier to change them. It also makes it possible to use a standard Policy Decision Point (PDP), so that organizations can make a proper make-or-buy decision. For virtually all organizations, authorization is not their core business, so being able to use an off-the-shelf product is appealing. Although these are substantial benefits, XACML really shines when authorizationis completely externalized from the application. Policies can then be reused across many applications, each using the same PDP. This leads to greater consistency of access control rules and improved efficiency in maintaining them.

The Akoma Ntoso standard defines a number of referenceable concepts that are used in many situations in the lifecycle of legal documents. The purpose of this section is to provide: a standard referencing mechanism to these concepts through the use of IRI references associated to classes and instances of an ad hoc ontology (the Akoma Notoso Naming Convention). The referencing mechanism is meant to be generic and evolving with the evolution of the underlying ontology; a set of requirements for other naming conventions to be usable within Akoma Ntoso XML resources in a proper way.

The Akoma Ntoso standard distinguishes between concepts regarding the description and identification of legal documents, their content, and the context in which they areused.  Names are used to associate the document representations to concepts so that documents can be “read/understood” by a machine, thus allowing sophisticated services that are impossible to attain with documents containing only typographical information, such as documents created in word-processing applications.To make documents machine-readable, every part with a relevant meaning and role must have a “name” (or “tag”) that machines can read. The content is marked up as precisely as possible according to the legal analysis of the text. This requires precisely identifying the boundaries of the different text segments, providing an element name that best describes the text in each situation, and also providing a correct identifier to each labelled fragment.

The present document contains objectives, requirements and test cases that are specific to the AUSF network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases given there, as well as specifying requirements and test cases unique to the AUSF network product class.

Standard Document:

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai...

The present document contains objectives, requirements and test cases that are specific to the SEPP network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases given there, as well as specifying requirements and test cases unique to the SEPP network product class.

Standard Document:

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai...

The present document contains objectives, requirements and test cases that are specific to the NRF network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases given there, as well as specifying requirements and test cases unique to the NRF network product class.

Standard Document:

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai...

The present document contains requirements and test cases that are specific to the NEF network product class. It refers to the Catalogue of General Security Assurance Requirements and formulates specific adaptions of the requirements and test cases given there, as well as specifying requirements and test cases unique to the NEF network product class.

Standard Document:

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai...

The scope of the present document is:

- Study for security between a 5G-RG and 5GC.
- Study for security for a 3GPP UE and non 3GPP UE behind a 5G-RG or a FN RG.
- Study for security for supporting legacy RG. The scope is limited based on the conclusion of the study in TR 23.716 [2].
- Study for security for trusted non-3GPP access.
- The privacy issues in the convergence architecture, if any.

Standard Document:

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai...

The scope of the present document is to analyse the security aspects of location service in 5G system and ensure the security solutions are aligned with the work in SA1 (i.e. in TS 22.261 [2] and TR 22.872 [3]) and SA2 (i.e. in TR 23.731 [4]). The work is comprised of the following parts:

- Study the security key issues, threats and requirements of location service in 5G system.
- Elaborate on the potential security solutions to cover these requirements.

Both non-roaming and roaming scenarios will be considered.

Standard Document:

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai...

The present document will examine potential security and privacy threat scenarios enabled by PARLOS, evaluate whether solutions need to be found for these and, if required, identify security solutions and approaches which can mitigate the identified security and privacy threat scenarios while meeting the US regulatory obligations spelled out in the referenced regulations. The present document will make recommendations on the solutions considered. The present document will consider user notification regarding security and privacy risks when using PARLOS.

The present document will consider the applicability of external security and privacy standards (e.g. Payment Card Industry Data Security Standard) to PARLOS.

Standard Document:

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetai...