**T****itle:** Information Technology - International Standardization
Profile ADY45 - The Directory Part 9 - DSA Access Control

**Source:** US National Committee for Information Technology Standards

(Editor: Wendy Brown, J. G. Van Dyke and Associates, Inc.)\
wbrown@jgvandyke.com

**Status:** For comment and approval

**Date:** 24 July, 1998

**Note:** Editor's notes are marked between \< \>, in courier font, and
in blue.

Contents

1 Scope [1](#scope)

1.1 General [1](#general)

1.2 Position Within the Taxonomy [1](#position-within-the-taxonomy)

1.3 Scenario [2](#scenario)

2 Normative References [5](#normative-references)

2.1 Paired ITU Recommendations \| International Standards equivalent in
technical content
[5](#paired-itu-recommendations-international-standards-equivalent-in-technical-content)

2.2 Normative Amendments and Technical Corrigenda
[6](#normative-amendments-and-technical-corrigenda)

2.3 Additional Normative References
[7](#additional-normative-references)

2.4 Informative References [7](#informative-references)

3 Definitions [7](#definitions)

3.1 General [7](#general-1)

3.2 Conformance definitions [8](#conformance-definitions)

3.3 Basic directory conformance definitions
[9](#basic-directory-conformance-definitions)

4 Abbreviations [9](#abbreviations)

5 Conformance [10](#conformance)

5.1 Conformance Statement [10](#conformance-statement)

5.2 Static Conformance Requirements
[11](#static-conformance-requirements)

5.2.1 General capability [11](#general-capability)

6 Procedures [12](#procedures)

6.1 Administrative Areas [12](#administrative-areas)

6.1.1 Autonomous Administrative Area (AAA)
[12](#autonomous-administrative-area-aaa)

6.1.2 Access Control Specific Area (ACSA)
[12](#access-control-specific-area-acsa)

6.1.3 Access Control Inner Area (ACIA)
[12](#access-control-inner-area-acia)

6.2 Subtree Specifications [13](#subtree-specifications)

6.3 SubEntries (see X.501 13.5.1) [13](#subentries-see-x.501-13.5.1)

6.4 ACI types [14](#aci-types)

6.4.1 ACI Types for SAC [14](#aci-types-for-sac)

6.4.2 ACI Types for BAC [14](#aci-types-for-bac)

6.5 Requestor [14](#requestor)

6.6 Authentication Level [15](#authentication-level)

6.6.1 none [15](#none)

6.6.2 simple [15](#simple)

6.6.3 strong [16](#strong)

6.7 Protected Items [16](#protected-items)

6.8 Permission Categories [16](#permission-categories)

6.9 User Classes [17](#user-classes)

6.10 Precedence (X.501 16.4.2.2) [17](#precedence-x.501-16.4.2.2)

6.11 Access Controls and Shadowing [18](#access-controls-and-shadowing)

Profile Requirements List [A-1](#profile-requirements-list)

Profile Specific Implementation Conformance Statement
[B-1](#profile-specific-implementation-conformance-statement)

# Figures {#figures .WW-Heading .unnumbered}

Figure 1 - DSAs Support of Access Control
[2](#__RefHeading___Toc424960987)

Figure 2 - Simplified Access Control Points
[3](#__RefHeading___Toc424960988)

Figure 3 - Basic Access Control Points [4](#__RefHeading___Toc424960989)

Figure 4 - Subtree specifications [13](#__RefHeading___Toc424960990)

# Foreword {#foreword .WW-Heading .unnumbered}

ISO (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized system
for world-wide standardization. National bodies that are members of ISO
or IEC participate in the development of International Standards through
technical committees established by the respective organizations to deal
with particular fields of technical activity. ISO and IEC technical
committees collaborate in fields of mutual interest. Other international
organizations, governmental or non-governmental, in liaison with ISO and
IEC, also take part in the work.

In the field of information technology, ISO and IEC have established a
joint technical committee, ISO/IEC JTC1.

An International Standardized Profile is an internationally agreed,
harmonized document which identifies a standard or group of standards,
together with options and parameters, necessary to accomplish a function
or set of functions.

Draft International Standardized Profiles are circulated to national
bodies for voting. Publication as an International Standardized Profile
requires approval by at least 75 % of the national bodies casting a
vote.

This ISP, ISO/IEC ISP 15125-9 was prepared with the collaboration of the
following organizations:

-   Asia-Oceania Workshop (AOW)

-   European Workshop for Open Systems (EWOS)

-   European Telecommunications Standards Institute (ETSI)

-   Open Systems Environment Implementor's Workshop (OIW)

ISO/IEC ISP 15125 consists of the following parts under the general
title *Information Technology-International Standardized Profiles
ISO/IEC ISP 15125 -The Directory*

-   Introduction

-   Supporting Layers

-   Part 0 - Common Upper Layer Requirements for the Directory

-   Part 1-ADY11: DUA support of Directory Access Protocol

-   Part 2-ADY12: DUA support of Distributed Operations

-   Part 3-ADY21: DSA support of Directory Access Protocol

-   Part 4-ADY22: DSA support of Distributed Operations

-   Part 5-ADY41: DUA Authentication as DAP initiator

-   Part 6-ADY42: DSA Authentication as DAP responder

-   Part 7-ADY43: DSA Authentication for DSP

-   Part 9-ADY45: DSA Access Control [^1]

-   Part 10-ADY51: Shadowing using ROSE

-   Part 11-ADY52: Shadowing using RTSE

-   Part 12-ADY53: Shadowing subset

-   Part 13-ADY61: Administrative areas

-   Part 14-ADY62: Establishment and utilization of shadowing agreements

-   Part 15-ADY63: Schema administration and publication

-   Part 16-ADY71: Shadowing Operational Binding

-   Part 17-ADY72: Hierarchical Operational Binding

-   Part 18-ADY73: Non-specific Hierarchical Operational Binding

ISO/IEC ISP 15126 consists of the following parts under the general
title *Information Technology-International Standardized Profiles
ISO/IEC ISP 15126 -The Directory*

-   Part 1-FDY11: Common Directory Use

```{=html}
<!-- -->
```
-   Part 2-FDY12: Directory System Schema

The present document contains two normative annexes:

-   Annex A: Profile Requirements List of ISO/IEC ISP 15125-9 - DSA
    Access Control

```{=html}
<!-- -->
```
-   Annex B: Profile Specific Implementation Conformance Statement (ICS)

# Introduction {#introduction .WW-Heading .unnumbered}

The concept and structure of International Standardized Profiles for
Information Systems are laid down in the Technical Report ISO/IEC TR
10000. The purpose of an International Standardized Profile is to
recommend when and how certain information technology standards shall be
used. This International Standardized Profile ISO/IEC ISP 15125
specifies application profile ADY45 as defined in the Technical Report
ISO/IEC TR 10000-2.

ISO/IEC ISP 15125 is one of a set of International Standardized Profiles
relating to the Directory (see TR 10000-2) for the \'93 standards.

ISO/IEC ISP 15125-9 profiles the manner in which DSAs support Access
Control, both in regards to required Operational Attributes and
observation of Access Controls in responding to DAP or DSP operations.

This International Standardized Profile (ISP) is defined within the
context of Functional Standardization, in accordance with the principles
specified by ISO/IEC TR 10000, \"Framework and Taxonomy of International
Standardized Profiles\". The concept of Functional Standardization is
one part of the overall field of Information Technology (IT)
standardization activities, covering base standards, profiles, and
registration mechanisms. A profile defines a combination of base
standards that collectively perform a specific well-defined IT function.
Profiles standardize the use of options and other variations in the base
standards, and provide a basis for the development of uniform,
internationally recognized system tests.

One of the most important roles for an ISP is to serve as the basis for
the development (by organizations other than ISO and IEC) of
internationally recognized tests and test methods. ISPs are produced not
simply to \"legitimise\" a particular choice of base standards and
options, but to promote real system interoperability. The development
and widespread acceptance of tests based on this and other ISPs is
crucial to the successful realisation of this goal.

The text of this ISP was developed in close co-operation among the
Directory Expert Groups of the three International OSI Workshops:

• OSE Implementors Workshop (OIW)

• The European Workshop for Open Systems (EWOS) and

• The OSI Asia-Oceania Workshop (AOW).

**Information Technology - International Standardized Profile 15125 -
The Directory**

**Part 9: DSA Access Control**

# Scope

## General

This part of ISO/IEC ISP 15125 (ADY 45) covers Simplified Access Control
(SAC) and Basic Access Control (BAC) as defined in 1993 ITU-T X.500
Series of Recommendations and ISO/IEC 9594 series of standards.

The objective of ISO/IEC ISP 15125-9 is to define capabilities and
constraints of Directory System Agents (DSAs) supporting Access Control.
Access Control is concerned with providing a means of controlling access
to Directory information within the Directory Information Base (DIB).
Controlling access to the Directory information includes prevention of
unauthorized detection, disclosure, or modification of that information.
Access Control is relevant both when the DSA is acting as responder to
Directory Access Protocol (DAP) requests from a Directory User Agent
(DUA) and as responder to Directory System Protocol (DSP) operations
from a peer DSA. Access Control information stored in the Directory will
be shadowed if the portion of the DIB to which it relates is part of a
shadowing agreement. In this case distribution of the access control
information will happen by way of Directory Information Shadowing
Protocol (DISP) and Directory Operational Binding Management Protocol
(DOP). There are no additional requirements on DISP within this profile.
There are no requirements on DOP within this profile.

This profile addresses both support for storing access control
information in the Directory and the use of Access Control information
when making access decisions in response to directory operations.

This profiles does not address DUA support for Access Control in
establishing and maintaining Access Control Information (ACI) in the
Directory.

This profile does not address the control of access to the DSA
application-entity.

## Position Within the Taxonomy

This part of ISO/IEC ISP 15125 is one part of a multipart ISP identified
in ISO/IEC TR 10000-2 as "ADY45, DSA Access Control".

This part of ISO/IEC ISP 15125 shall be combined with the following
profiles:

-   Part 3--ADY21: DSA support of Directory Access

-   Part 6--ADY42: DSA Authentication as DAP responder

-   Part 13--ADY61: Administrative areas

    ISO/IEC ISP 15125-3 (ADY21) addresses the requirements for support
    of DAP by a DSA to allow DUAs to interwork with the Directory.

    ISO/IEC ISP 15125-6 (ADY42) addresses the behavior of DSAs when
    authenticating DUAs initiating a bind using simple protected
    authentication or strong authentication.

    ISO/IEC ISP 15125-13 (ADY61) addresses the requirements for
    subdivision of the Directory Information Tree (DIT) into
    administrative areas for the purpose of Access Control (and other
    purposes) and the operational attributes that must be supported.

    This part of ISO/IEC ISP 15125 may be combined with the following
    profiles:

-   Part 4--ADY22: DSA support of Distributed Operations

-   Part 7--ADY43: DSA Authentication for DSP

ISO/IEC ISP 15125-4 (ADY22) and ISO/IEC ISP 15125-7 (ADY43) address the
behavior required by a DSA to ensure the ability to interwork in the
Directory in support of Distributed Operations.

ISO/IEC ISP 15125-7 (ADY43) addresses the behavior of DSAs when
authenticating other DSAs initiating a bind using simple protected
authentication or strong authentication. It also addresses the use of
the originator element, which is passed using DSP from one DSA to
another.

## Scenario

Access Control is performed by DSAs to determine if a requestor is
allowed access to the requested information stored in the DSA. The DSA
compares a presented DAP or DSP request for information to the stored
information's **ACIItem**, and then performs an access control decision
function to determine whether permission to access the information
should be granted or denied to the requestor.

![](media/image1.wmf){width="6.426388888888889in"
height="2.4305555555555554in"}

[]{#__RefHeading___Toc424960987 .anchor}Figure 1 - DSAs Support of
Access Control

In SAC, access control decisions are made only on the basis of
**ACIItem** values of **prescriptiveACI** and **subentryACI**
operational attributes**; these may only be associated with Access
Control Specific Entries (Access Control Inner Entries are not supported
by SAC)**. **prescriptiveACI** are located in subentries to the
administrative entry. **subentryACI** are placed in administrative
entries. **subentryACI** protect the information contained in
subentries, while **prescriptiveACI** protect information in the entries
of the Access Control Area.

![](media/image2.wmf){width="5.0in" height="3.75in"}

[]{#__RefHeading___Toc424960988 .anchor}Figure 2 - Simplified Access
Control Points

In BAC access control decisions are made on the basis of **ACIItem**
values of **prescriptiveACI**, **subentryACI** and **entryACI**
operational attributes. **prescriptiveACI** and **subentryACI** may be
associated with the administrative point of an Access Control Specific
Area (ACSA) or an Access Control Inner Area (ACIA). **entryACI** can
only be associated with a particular entry or **subentry**.
**prescriptiveACI** are located in subentries to the administrative
entry. **subentryACI** are placed in administrative entries.
**subentryACI** protect the information contained in subentries, while
**prescriptiveACI** protect information in the entries of the Access
Control Area. The use of ACIAs permits a superior authority within the
Security Authority to delegate access control decisions to subordinate
authorities associated with each ACIA.

![](media/image3.wmf){width="5.0in" height="3.75in"}

[]{#__RefHeading___Toc424960989 .anchor}Figure 3 - Basic Access Control
Points

# Normative References

The following ITU-T Recommendations and International Standards contain
provisions which, through references in this text, constitute provisions
of this International Standardized Profile. At the time of publication,
the editions indicated were valid. All documents are subject to
revision, and parties to agreements based on this International
Standardized Profile are warned against automatically applying any more
recent editions of the documents listed below, since the nature of
references made by ISPs to such documents is that they may be specific
to a particular edition.

Members of IEC and ISO maintain registers of currently valid
International Standards and ISPs, and ITU-T maintains published editions
of its current Recommendations.

##  Paired ITU Recommendations \| International Standards equivalent in technical content

-   ITU-T Recommendation X.500 (1993) \| ISO/IEC 9594-1:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Overview of concepts, models and services.*

-   ITU-T Recommendation X.501 (1993) \| ISO/IEC 9594-2:1995,
    I*nformation technology \-- Open Systems Interconnection \-- The
    Directory: Models.*

-   ITU-T Recommendation X.511 (1993) \| ISO/IEC 9594-3:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Abstract service definition.*

-   ITU-T Recommendation X.518 (1993) \| ISO/IEC 9594-4:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Procedures for distributed operations.*

-   ITU-T Recommendation X.519 (1993) \| ISO/IEC 9594-5:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Protocol specifications.*

-   ITU-T Recommendation X.520 (1993) \| ISO/IEC 9594-6:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Selected attribute types.*

-   ITU-T Recommendation X.521 (1993) \| ISO/IEC 9594-7:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Selected object classes.*

-   ITU-T Recommendation X.509 (1993) \| ISO/IEC 9594-8:1995,
    I*nformation technology \-- Open Systems Interconnection \-- The
    Directory: Authentication framework.*

-   ITU-T Recommendation X.525 (1993) \| ISO/IEC 9594-9:1995,
    *Information technology \-- Open Systems Interconnection \-- The
    Directory: Replication.*

-   ITU-T Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997,
    *Information technology \-- Open Systems Interconnection -Directory
    Access Protocol: Protocol Implementation Conformance Statement
    (PICS) Proforma.*

-   ITU-T Recommendation X.680: 1994 \| ISO/IEC 8824-1:1994,
    I*nformation technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Specification of basic
    notation.*

-   ITU-T Recommendation X.681: 1994 \| ISO/IEC 8824-2:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Information Object
    Specification.*

-   ITU-T Recommendation X.682: 1994 \| ISO/IEC 8824-3:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Constraints Specification.*

-   ITU-T Recommendation X.683: 1994 \| ISO/IEC 8824-4:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1
    specification.*

-   ITU-T Recommendation X.684: 1994 \| ISO/IEC 8825-1:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Specification of Abstract Syntax Notation One (ASN.1) Encoding
    Rules: Basic, Canonical and Distinguished Encoding Rules.*

-   ITU-T Recommendation X.880: 1994 \| ISO/IEC 13712-1:1994,
    *Information technology - Open Systems Interconnection (OSI) -
    Remote Operations: Concepts models and notation.*

-   ITU-T Recommendation X.881: 1994 \| ISO/IEC 13712-2:1994,
    *Information technology - Open Systems Interconnection (OSI) - OSI
    Realizations - Remote Operations Service Element (ROSE) service
    definition.*

-   ITU-T Recommendation X.882: 1994 \| ISO/IEC 13712-3:1994,
    *Information technology - Open Systems Interconnection (OSI) - OSI
    Realizations - Remote Operations Service Element (ROSE) protocol
    specification.*

## Normative Amendments and Technical Corrigenda

-   Technical Corrigendum 1 to Recommendation X.501 (1993) \| ISO/IEC
    9594-2:1995 (covering resolutions to defect reports 088, 089, 090,
    091, 102, 104, 125)

-   Draft Technical Corrigendum 2 to Recommendation X.501 (1993) \|
    ISO/IEC 9594-2:1995 (covering resolutions to defect reports 134,
    136, 140, 143, 144, 145, 147, 149, 171, 172, 174)

-   Technical Corrigendum 1 to Recommendation X.509 (1993) \| ISO/IEC
    9594-8:1995 (covering resolutions to defect report 128)

-   Technical Corrigendum 2 to Recommendation X.509 (1993) \| ISO/IEC
    9594-8:1995 (covering resolutions to defect report 077, 078, 083,
    084)

-   Draft Technical Corrigendum 3 to Recommendation X.509 (1993) \|
    ISO/IEC 9594-8:1995 (covering resolutions to defect report 80, 92,
    100, 177, 183, 194, 196)

-   Technical Corrigendum 1 to Recommendation X.511 (1993) \| ISO/IEC
    9594-3:1995 (covering resolutions to defect report 085)

-   Draft Technical Corrigendum 2 to Recommendation X.511 (1993) \|
    ISO/IEC 9594-3:1995 (covering resolutions to defect reports 104,
    119, 133, 137, 138, 148, 150, 175)

-   Technical Corrigendum 1 to Recommendation X.518 (1993) \| ISO/IEC
    9594-4:1995 (covering resolutions to defect reports 094, 106, 108,
    109, 111, 112, 113, 114, 115)

-   Draft Technical Corrigendum 2 to Recommendation X.518 (1993) \|
    ISO/IEC 9594-4:1995 (covering resolutions to defect reports 116,
    117, 118, 119, 120, 121, 130, 152, 153, 154, 155, 156, 158, 160,
    161, 165, 167)

-   Technical Corrigendum 1 to Recommendation X.519 (1993) \| ISO/IEC
    9594-5:1995 (covering resolutions to defect reports 075, 124)

-   Draft Technical Corrigendum 2 to Recommendation X.519 (1993) \|
    ISO/IEC 9594-5:1995 (covering resolutions to defect reports 127,
    139)

-   Technical Corrigendum 1 to Recommendation X.520 (1993) \| ISO/IEC
    9594-6:1995 (covering resolutions to defect reports 076, 122, 127)

-   Draft Technical Corrigendum 2 to Recommendation X.520 (1993) \|
    ISO/IEC 9594-6:1995 (covering resolutions to defect reports 135,
    146)

-   Technical Corrigendum 1 to Recommendation X.525 (1993) \| ISO/IEC
    9594-9:1995 (covering resolutions to defect reports 097, 099, 123)

-   Draft Technical Corrigendum 2 to Recommendation X.525 \| ISO/IEC
    9594-9:1995 (covering resolutions to defect reports 132, 141, 142)

## Additional Normative References

-   CCITT Recommendation X.200 (1988) Reference Model of Open Systems
    Interconnection for CCITT Applications.

-   ISO 7498:1984, *Information Processing Systems - Open Systems
    Interconnection - Basic Reference Model.*

-   ISO/IEC 9646-1:1994, *Information technology \-- Open Systems
    Interconnection \-- Conformance testing methodology and framework -
    Part 1: General concepts.*

-   ISO/IEC 9646-7:1995, *Information technology \-- Open Systems
    Interconnection \-- Conformance testing methodology and framework -
    Part 7: Implementation conformance statements*

-   ISO/IEC TR 10000-1:1995, *Information Technology - Framework and
    taxonomy of International Standardized Profiles - Part 1:
    Framework.*

```{=html}
<!-- -->
```
-   ISO/IEC TR 10000-2:1995, *Information Technology - Framework and
    taxonomy of International Standardized Profiles - Part 2: Taxonomy
    of Profiles*

## Informative References

Understanding X.500 The Directory, David Chadwick, International Thomson
Computer Press, 1996.

# Definitions

For the purpose of this part of ISO/IEC ISP 15125, the following
definitions apply

## General

Many of the definitions used may be found in the Standards. Since not
all of the definitions are to be found in the Definitions clauses within
the standards documents, references are listed in Table 1 below. The
\"Part\" reference refers to the part number within ISO/IEC 9594 or its
ITU-T equivalent.

  -----------------------------------------------------------------------
  Term                                    Part       Reference
  --------------------------------------- ---------- --------------------
  access control scheme                   2          15.1

  administrative area                     2          10.1

  administrative entry                    2          10.1

  administrative point                    2          10.1

  autonomous administrative area          2          10.1

  base                                    2          11.1

  chop                                    2          11.1

  entry                                   2          11.1

  inner administrative area               2          10.1

  administrative model                    2          10

  administrativeRole                      2          13.3

  base object                             4          3.6

  Basic Access Control                    2          16

  DSA information tree                    2          19.1.1

  knowledge (information)                 2          18.1

  knowledge reference                     2          18.1

  master knowledge                        2          18.1

  modification operations                 4          3

  operational attribute                   2          8.1,11.2

  operational binding                     2          22.1

  originator                              4          3

  performer                               4          3

  policy                                  2          10.3

  Simplified Access Control               2          16.9

  specific administrative area            2          10.1

  subentry                                2          11.1

  subtree                                 2          11.1

  subtree refinement                      2          11.1

  subtree specification                   2          11.1
  -----------------------------------------------------------------------

## Conformance definitions

The following terms are defined in ISO/IEC 9646:

> a\) Protocol Implementation Conformance Statement (PICS);
>
> b\) PICS Proforma;
>
> c\) Profile Requirements List (PRL)
>
> d\) conformance;
>
> e\) mandatory requirement;
>
> f\) optional requirement;
>
> g\) conditional requirement.

## Basic directory conformance definitions

Terms used in this part of ISO/IEC ISP 15125 are as defined in the
referenced base standards. In addition, the following terms are defined.

**Chaining DSA**: a cooperating DSA that is capable of invoking chained
operations, functioning as a DSP invoker. A chaining DSA is also a
cooperating DSA.

**Cooperating DSA**: a DSA that is capable of holding knowledge
references. Such a DSA is capable of returning referrals, and may also
be a chaining DSA.

# Abbreviations

AAA Autonomous Administrative Area

AAP Autonomous Administrative Point

ACDF Access Control Decision Function

ACIA Access Control Inner Area

ACSA Access Control Specific Administrative Area

ASN.1 Abstract Syntax Notation One

CCITT International Telegraph and Telephone Consultative Committee

DACD Directory Access Control Domain

DAP Directory Access Protocol

DIB Directory Information Base

DISP Directory Information Shadowing Protocol

DIT Directory Information Tree

DMD Directory Management Domain

DN Distinguished Name

DOP Directory Operational Binding Management Protocol

DSA Directory System Agent

DSP Directory System Protocol

DUA Directory User Agent

IEC International Electrotechnical Commission

IPRL ISPICS Requirements List

ISO International Organization for Standardization

ISP International Standardized Profile

ISPICS ISP Implementation Conformance Statement

ITU International Telecommunication Union

ITU-T ITU Telecommunication Standardization Sector

OSI Open Systems Interconnection

PDU Protocol Data Unit

PICS Protocol Implementation Conformance Statement

PRL Profile Requirements List

ROSE Remote Operations Service Element

# Conformance

The Directory Standards state only limited conformance within the scope
of this ISP:

To conform to this part of ISO/IEC ISP 15125, implementations shall
conform to all of the requirements of

-   ISO/IEC 9594-1 clause 11.2, clause 11.5,

-   ISO/IEC 9594-2 clause 11.6, clause 13.5, clause 16, and clause 15,
    Annex D,

-   ISO/IEC 9594-3 clause 7.11, clause 9.1.5, clause 9.2.5, clause
    10.1.5, clause 10.2.5, clause 11.1.5, clause 11.2.5, clause 11.3.5,
    clause 11.4.5, Annex B,

-   ISO/IEC 9594-4 clause 22,

-   ISO/IEC 9594-5 clause 9.2,

-   and if DSP is supported, ISO/IEC 9594-4, clause 22.1,

including the requirements directly and indirectly referenced by these
clauses.

For an implementation to conform to this part of ISO/IEC ISP 15125, the
behavior of each operation and protocol element, whether supported or
not, shall conform to the provisions of this part of ISP/IEC ISP 15125.

Annex A states the relationship between the requirements of this part of
ISO/IEC ISP 15125 and those of the base standards.

## Conformance Statement

For each implementation claiming conformance to ISO/IEC ISP 15125-6, an
appropriate set of PICS, ITU-T Recommendation X.583 (1997) \| ISO/IEC
13248-1: 1997 and/or , ITU-T Recommendation X.584 (1997) \| ISO/IEC
13248-2: 1997, shall be produced stating the support or non-support of
each option identified.

The PICS shall satisfy all DSA requirements defined in ISO/IEC
9594-5:1995 \| ITU X.519 (1993), part 3 of this ISP (ISO/IEC ISP
15125-3) for DAP access control and/or part 4 of this ISP (ISO/IEC ISP
15125-4) for DSP access control, in addition to the PRL found in Annex A
and the Profile Specific ICS found in Annex B of this document.

When combined, some features that are found in Annex A of this document
will overlap features found in the PRLs of ISO/IEC ISP 15125-3 and
ISO/IEC ISP 15125-4. In those cases the requirements defined in this
part of the ISP will take precedence.

ITU-T Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997 covers all
aspects of the DAP protocol. For the purpose of conformance for this
part of the ISP the implementation need only demonstrate support
appropriate to this part of the ISP (e.g. DSA column).

DSAs conformant with this part of the ISP shall claim conformance to one
or more of the following:

\- Simple Access Control (SAC).

\- Basic Access Control (BAC)

## Static Conformance Requirements

Each feature (operation or protocol element) listed in Annex A is
designated as having a support requirement of mandatory, optional,
conditional, excluded, out-of-scope, or not applicable. Some features
have a conditional designation specifying whether the feature is
mandatory or optional based on a predicate. The conditions and
predicates are stated in the PRL. Implementations shall support all
features designated mandatory in the PRL except those that are part of
an unsupported protocol element. Where protocol elements are nested, the
requirement to support the nested element is relevant only when the
immediately containing element is supported.

N**ote**: In the IPRL defined in Annex A of this part of ISO/IEC ISP
15125, the conformance requirement of the protocol elements at the
highest level is of relevance only when the related operation is
supported. In the X.500 PICS Proformas, this is stated as c:m in the
Protocol Status column.

### General capability

DSAs conforming to this ISP shall be capable of supporting
administrative entries and access control **subentries**. An
administrative entry holds an **administrativeRole** attribute and is
special in that it is the only kind of entry that is permitted to have
**subentries** or to hold **subentry-ACI** or **access-control-scheme**
attributes**.** Since it is associated with policies, it is sensitive.
DSAs claiming support to BAC shall be capable of supporting the values
**id-ar-accessControlSpecificArea** and **id-ar-accessControlInnerArea**
in the **administrativeRole**. Access control **subentries** are only
permitted when subordinate to administrative entries that contain these
values in their administrative role attribute. DSAs claiming support to
SAC shall be capable of supporting the value
**id-ar-accessControlSpecificArea** in the **administrativeRole.** In
addition, DSAs shall support the accessControlScheme operational
attribute, which is a mandatory operational attribute for entries with
an **id-ar-accessControlSpecificArea** value in the administrativeRole
attribute.

DSAs conformant with this ISP shall be capable of supporting the
following operational attributes of an administrative entry:

1.  The **administrativeRole** attribute as described in ISO/IEC ISP
    15126-2 (FDY12), clause 7.3.1.1

2.  Supporting the **accessControlScheme** operational attribute as
    described in ISO/IEC ISP 15126-2 (FDY12), clause 7.3.2.1. If BAC is
    claimed the DSA shall accept the value of **basic-access-control**.
    If SAC is claimed the DSA shall accept the value of
    **simplified-access-control**.

3.  Supporting **subEntryACI** operational attributes as described in
    ISO/IEC ISP 15126-2 (FDY12), clause 7.3.2.2.

4.  Supporting **subentries** as described in ISO/IEC ISP 15126-2
    (FDY12), clauses 7.3.3 and 7.3.4, and accepting all operations in
    which subentries can be involved

5.  Handling the operational attribute **subtreeSpecification** of a
    subentry according to the type of the associated access control
    specific or access control inner area and as described in clause
    7.3.3.2 of ISO/IEC ISP 15126-2 (FDY12), (The elements that are to be
    supported in subtree specifications are described in ISO/IEC ISP
    15125-13 (ADY61).)

6.  Supporting **prescriptiveACI** operational attributes as described
    in ISO/IEC ISP 15126-2 (FDY12), clause 7.3.3.6.

A DSA that supports both BAC and SAC should be able to simultaneously
support BAC and SAC in different parts of the portion of the DIT that it
contains. Therefore:

DSAs that support both BAC and SAC shall be able to have different
access control schemes in different **accessControlScheme** operational
attributes.

> Note. Administrative points are recorded as such in the **DSEType**
> operational attribute.

# Procedures

X.500 Access Controls are very flexible in providing great granularity
as far as the permissions granted or denied to information stored in the
Directory. Protected items can include entire entries, specific
attributes or even specific values of attributes within an entry.
Permissions can be granted or denied to specific users, groups of users
identified by membership in a group or placement in the Directory, or to
the general public. Implementing a security policy may require that
multiple access control rules be set. A security authority needs to take
into account the cumulative access granted or denied by all ACI set
within an administrative area.

Table K-1 in X.501 shows the permissions required to perform directory
operations. When evaluating access controls, for read, list, or search
oparations if a required permission has not been granted for all
requested information, only part of the operation will fail. If there
are other parts to the operation, these will continue. For update
operations, any failure of access control will cause the complete
operation to fail, and the underlying data base will be left unchanged.
For example, operations like Search will continue even though it has
been unable to access some of the entries. When protecting an entry, it
is important to consider all the operations that may be performed. For
instance, search does not require Read permission for entry access (it
uses the potentially more restrictive Browse permission), therefore
denying Read entry permission and forgetting to deny the Browse
permission may still allow access to some of the contents of that entry
through a search.

Specificity is important when resolving access control information for a
given user and protected item. If the precedence of two ACI items are
equal, the one with the most specific information, either for users or
protected items will overrule. If two ACI items exist with the same
precedence and specificity but differ in their grant/deny permission,
the deny will overrule the grant. Similarly, the specificity of users is
important: a user that is defined in the more specific way (e.g. by
name) has higher precedence than a user who is defined more generally
(e.g. all-users).

## Administrative Areas

To support Access Control, the DSA must support the object classes and
attributes required for support of the following types of administrative
areas. The DSA shall be capable of supporting administrative areas as
described in ISO/IEC ISP 15125-13 (ADY61), clause 5.2.4.1.

### Autonomous Administrative Area (AAA)

An AAA is defined by an administrative entry and is an implicitly
defined subtree beginning at the autonomous administrative point (AAP)
and ending either at leaf nodes or when another AAP is encountered. An
Autonomous Administrative Point is considered implicitly to be an Access
Control Specific Point for the purpose of this description, even if it
is not associated with any prescriptive controls. Such an entry, which
has neither an ACSA role or an AC-scheme attribute implements neither
SAC or BAC, and may (for example) give unrestricted read/browse access.

### Access Control Specific Area (ACSA)

An ACSA is designated by an administrative entry with an
**administrative-role** attribute with the value
**id-ar-accessControlSpecificArea.** An ACSA represents an autonomous
security policy; no access control information stored within another
ACSA will influence access decisions in the first ACSA. An AAA
representing a single organization may be subdivided into multiple ACSA
representing divisions of that organization if each division is to have
sole discretion over its own security policies.

### Access Control Inner Area (ACIA)

An ACIA is designated by an administrative entry with an
**administrative-role** attribute with the value
**id-ar-accessControlInnerArea.** A DSA supporting SAC shall not use an
ACIA**.**

If a security authority wants to delegate some access control
responsibility to a subordinate authority and retain some control, this
can be done by defining one or more ACIAs. ACIAs are considered nested
within the containing ACSA. This means access control decisions look
both at the ACI associated with the ACSA and any nested ACIAs.

## Subtree Specifications 

DSAs claiming conformance to Access Control shall support Subtree
specifications to comply with clause 11.3 of ISO/IEC 9594-2, and clause
5.2.4.2.3 of ISO/IEC ISP 15125-13 (ADY61).

![](media/image4.wmf){width="4.05in" height="2.725in"}

[]{#__RefHeading___Toc424960990 .anchor}Figure 4 - Subtree
specifications

Subtrees can be used to define Directory Access Control Domains (DACDs).
A DACD is used to represent the entries or potential entries which are
targeted by a specific subtree specification An access control
administrative area, either specific or inner, can contain a number of
subentries describing the same or a different collection of entries
within that access control area. Each subentry contains one subtree
specification attribute that explicitly states where the DACD starts,
optionally where it ends, and what entries within that area are included
(specification filter). The bottom end of a DACD can be defined
implicitly by encountering a new access control specific area. Access
control policies governing all the entries covered by that DACD are
stored as **prescriptiveACI** operational attributes in a subentry with
a subtree specification corresponding to the DACD.

When determining access to information in a particular entry, the DSA
must take into account any entry ACI associated with that entry. The DSA
must traverse up the DIT from the specified entry to the first specific
administrative point looking for administrative points with an
administrativeRole containing either access control inner area or access
control specific area. Each access control area is checked to see if the
subtree specification contains the entry. Once an access control
specific point is encountered, the traversing stops.

> Note. The concept of traversing is for description purposes, since an
> entry has a static relationship with its corresponding access control
> administrative points which can be remembered by an implementation for
> later optimised use.

## SubEntries (see X.501 13.5.1)

The **subEntry** object class shall be supported as described in ISO/IEC
ISP 15126-2 (FDY12) and ISO/IEC ISP 15125-13 (ADY61), clause 5.2.4.2. If
a subentry contains prescriptive access control information, then its
**objectClass** attribute shall contain the value
**accessControlSubentry.** A subentry of this object class shall contain
precisely one prescriptive ACI attribute of a type consistent with the
value of the **id-sc-accessControlScheme** attribute of the
corresponding access control specific point.

## ACI types

All ACI types can be multi-valued.

**entryACI** attributes are operational attributes stored with an entry
that protect both user and operational attributes associated with that
particular entry. They can also be used to protect collective attributes
that apply to that entry. However, entryACI attributes do not influence
access to any other entry.

**prescriptiveACI** are operational attributes that can only be held in
subentries of either ACSA or ACIA administrative points. They protect
the entries, and their associated attributes, which are within the scope
of the access control domain defined by the subtree specification of the
of the subentry that contains them.

**subentryACI** are operational attributes that can only be held in
administrative entries. They protect the subentries and operational and
user attributes contained in the subentries immediately below the
administrative point in which the **subentryACI** resides.

Note: Not all administrative points are access control administrative
points. Subentry-ACI can be used to protect subentries for any purpose
(e.g. collective attribute subentries)

### ACI Types for SAC

The DSA must support **prescriptiveACI.**

The DSA must support **subentryACI**.

An access control subentry is only permitted when subordinate to an
administrative entry with **id-ar-accessControlSpecificArea** **or
id-ar-accessControlInnerArea** administrative role. Access control
subentries subordinate to administrative entries with
**accessControlInnerArea administrative roles** are ignored in the
context of SAC. Note that an administrator may wish to prepare for BAC
while still using SAC (e.g. to give special protection at a later date
to particular entries), by placing entryACI in entries.

**entryACI** shall not be used and if present shall be ignored by the
DSA when making access control decisions within an ACSA with
**simplified-access-control** as the value of the operational attribute
**accessControlScheme** for the corresponding access control specific
point.

### ACI Types for BAC

The DSA must support **prescriptiveACI** and **entryACI. subentryACI**
shall be stored within ACSAs or ACIAs, to protect subentries of these
containing **basic-access-control** as the value of the operational
attribute **accessControlScheme**

The DSA may optionally also support **subentryACI**. If the DSA it does
not support subentry ACI, it must support some other means of protecting
its subentries. Entry ACI can be used for this purpose.

An access control subentry is only permitted when subordinate to an
administrative entry with **id-ar-accessControlSpecificArea** **or
id-ar-accessControlInnerArea** administrative role.

## Requestor

The **requestor** Distinguished Name holds the name of the user,
identified at the time of binding to the Directory, originating a
particular operation. (ISO/IEC 9594-3 7.3) The requestor element in
common arguments is never required, and is in any case suspect since it
is supplied by the user of the moment and not by the authenticated
entity.

If a user binds directly to a DSA, that DSA can use the resulting
authenticated identity for the purposes of access control. Access
control is given greater security when signed operations are used: in
this case, the identity comes from the owner of the corresponding
certificate (who may also be given a unique identifier by the
certificate).

When the operation is provided to a DSA by DSP, there are two
situations. If the operation is signed, the DSA can use the identity in
a signature for the purposes of access control, although, of course, it
may have to take into account the fact that the source DSA cannot
necessarily be trusted to protect the returning information. If that DSA
operation is not signed, the identity of the user is supplied by the
originator field in the DSP operation. The DSA that receives such an
originator field may believe it or not according to the trust that it
provides to the source DSA. For example, the originator may be advised
by the source DSA that the user was strongly authenticated; the DSA is,
all the same, entitled to treat the operation as if the user had simple
(or even no) authentication, if the source DSA was inadequately trusted.
ISO/IEC ISP 15125-7 (ADY43) gives details about this matter.

A chaining DSA may put the DN of the **requestor** either in the
originator field of **ChainingArguments** or leave it in the
**requestor** field of the **CommonArguments** if present in this field,
the DSA must leave it there, unless the request initiator is already
identified in the **securityParameters.** In any case,
**authenticationLevel** of the **ChainingArguments** will be filled to
indicate to the target DSA the manner in which authentication was
assumed to have been carried out at the original access point to the
Directory.

If the initiator of a request is identified in the
**securityParameters**, using the **certification-path**, this may be
used by the target DSA to authenticate the requestor without requiring
additional directory lookups, other than those used to validate the
certificate and other components of the certification path. If the
**requestor** is identified either in the originator field of
**ChainingArguments** or in the **requestor** field of the
**CommonArguments**, the target DSA may, but need not, rely on the
requesting DSA having previously performed authentication of the
requestor.

> Note: Where a user has alternative distinguished names differentiated
> by context, the name used as the value of **requestor** shall be the
> primary distinguished name, where known. Otherwise access control
> based on the value of **requestor** may not work as desired.

## Authentication Level

Since Access Control decisions are based on the identity of the DAP
requestor, what type of authentication takes place at the DSP bind may
not be relevant, therefore, the question of support for
authenticationLevel is only asked once in table A.3.1. The level of
trust that a DSA may accord to the source of DSP operations can depend
on the quality of DSP bind authentication. It can also be enhanced by
the use of signed DSP operations. The use of trust in this way is a
local matter.

DSAs must support **basicLevels**, support for **other** is optional.
Within **basicLevels**, the **level** is mandatory and the values that
must be supported are enumerated below. Support for **localQualifier**
is optional.

Support for at least one of **simple** or **strong** authentication is
required. Access control may be granted or denied to allUsers as part of
a series of policies, which in total build up the complete policy. It is
possible that access control can be absolutely denied to all users in
the case of operational attributes that may only be seen by
administrative users using special tools.

If the DSA is a chaining DSA, it must support passing the requestor or
originator and authenticationLevel elements when chaining. However, the
receiving DSA may use different originator and authenticationLevel
values, depending on the level of trust accorded to the source DSA. For
example, the originator element may be permitted completely to signify
an unknown user, even if the DSA was supplied with an originator field
on its own incoming DSP operation.

### none

Support for the **none** field in the **AuthenticationLevel** may be
used in order to allow public access to certain areas or information
within the Directory. Therefore DSAs shall support the
**AuthenticationLevel none**.

### simple

DSAs which support the **simple** field in the **AuthenticationLevel**
shall be implemented in accordance with ISO/IEC ISP 12125-3 (ADY21)
and/or ISO/IEC ISP 12125-6 (ADY42), or ISO/IEC ISP 12125-7 (ADY43) for
either DAP or DSP, respectively. DSAs acting as responders to DSP
requests, may trust the DSA chaining the request and rely on the
**requestor** and **AuthenticationLevel** as passed.

### strong

DSAs which support the **strong** field in the **AuthenticationLevel**
shall be implemented in accordance with ISO/IEC ISP 12125-6 (ADY42) or
ISO/IEC ISP 12125-7 (ADY43) for either DAP or DSP, respectively. DSAs
acting as responders to DSP requests, may, but need not, trust the DSA
chaining the request and rely on the **requestor** and
**AuthenticationLevel** as passed.

> Note. It isn't necessary for a DSA to support strong authentication
> for it to support this value.

## Protected Items

DSAs that conform to this ISP shall support the **protectedItems** for
**Entry**, **allUserAttributeTypes** and **attributeType**. It is
assumed that the same **protectedItems** are supported in either
**itemFirst** or **userFirst**.

If access controls are being used, it is necessary to be able to set
protections on an Entry in order to allow users to access information at
all. Access controls can be set on Attribute Types, regardless of
whether the attribute is currently specified in an entry. What it means
to set protections on a value is a little less clear., In some cases,
the value must be present in the entry and if the value changes, the
specified access control is no longer relevant, therefore it is of less
use to be able to protect the variations on value. Some values are
special -- e.g. object-class values, or values associated with
attributes with enumerated potential values. To protect an actual value
in an attribute is effectively saying that an entry has an attribute
that can contain a number of values and one or more particular values
require protection (If all values require protection then protect the
attribute). If this situation arises then perhaps the values requiring
protection should actually be placed in another attribute.

There is also the question as to what does update access to a particular
value imply. If the value is changed then the access control may no
longer apply.

If an ACI is associated with a particular value, it might make sense to
expect the DSA to automatically change the ACI if the associated values
is operated on in the following manner:

-   If the value is modified, modify the associated ACI to be for the
    new value

-   If the value is removed, remove the ACI, so the directory is not
    left with an ACI hanging.

However, there is nothing in the standard that suggests a DSA should
make these automatic operations. In addition, it is possible the ACI is
actually associated with the value found in multiple entries in the DACD
and therefore changing the value in only one entry may not invalidate
the ACI for other entries. Therefore, no automatic tracking of ACI Items
to operations on values should be assumed.

Value access control in the absence of support for value level access
control should be applied as follows:

Where all-values are specified by an ACI item, the issue of value access
control doesn\'t apply.

Where individual values are specified, no access control is granted to
*other* values in the case of an ACI item specifying a grant; access
control is *denied* to all values in the case of an ACI item specifying
a denial.

The consequence of this policy is that having access to the type but not
to the values will result in the type but not the values being
accessible.

In the absence of supporting any access controls on value, access
granted to an attribute type implies the same access to associated
values.

## Permission Categories

The base PICS state that it is mandatory for all DSAs to support all
permission categories. DSAs shall support the same **grantsAndDenials**
in either **ItemPermission** or **UserPermission**. The PICS and
therefore the base standard make support for all **grantsAndDenials**
mandatory.

It is especially important for a DSA to fully support both the grant and
deny permission categories for DiscloseOnError for both attribute and
entry. Grant DiscloseOnError may be useful for a directory administrator
attempting to track down problems in the DIB, while deny DiscloseOnError
is necessary to avoid disclosing information about the makeup of the
Directory to other users.

If deny returnDN is specified , the Directory shall return a valid alias
instead of the DN, or if no alias name is available shall fail the
operation with a **NameError** (in the case of Read) or omit the entry
from the results (in the case of Search). If the entry was found using
an alias, the DSA knows a valid alias to return. If the entry was found
directly, a mechanism is required to determine a valid alias to be
returned. One possible mechanism might be an operational attribute,
which specifies the name to be returned. (X.511 7.11.1.4)

## User Classes

The DSA shall support the following **UserClasses**:

-   **allUsers**

    **allUsers** is used in specifying what permissions are granted to
    the general public or users not more specifically mentioned in ACI.

-   **thisEntry**

    **thisEntry** means the user whose name matches the DN of the entry
    being accessed.

-   **Name**

    **name** is the distinguished name of a specific user. It may be
    enhanced by a unique identifier, which can be derived from the
    certificate when strong authentication is used.

-   **subtree**

    **subtree** specifies the distinguished name of a non-leaf node in
    the DIT and optionally a chop specification. This specifies all the
    users who match entries that fall within the subtree specification.
    Support requirements for subtree specifications can be found in
    ISO/IEC ISP 15125-13 (ADY61) 5.2.4.2.3 and ISO/IEC ISP 15126-2
    (FDY12) 7.3.3.2.

    The following **UserClass** may optionally be supported:

-   **userGroup** (see X.501 16.4.2.5)

    Support for userGroup is useful in setting up access control lists
    (ACL) that can then be used in ACIItems. Therefore support is
    recommended, though not mandatory. When **userGroup** is used, the
    entry named by the **userGroup** specification must be an instance
    of the object class **groupOfNames** or **groupOfUniqueNames**. The
    name of the requestor must be a value of the **member** or
    **uniqueMember** attribute of that entry. Nested **userGroups** are
    not supported. Access control is granted to users on the basis of
    their membership in a particular user group, and is not granted to
    the group in its own right (this is different to the situation for
    UNIX). Therefore a nested group cannot have access, because it
    cannot have an authenticated identity, and will simply be ignored.

## 6.10 Precedence (X.501 16.4.2.2) {#precedence-x.501-16.4.2.2 .unnumbered}

A DSA that supports Access Control shall support **precedence** in
**ItemPermissions** and **UserPermissions**, as well as in **ACIItems.**

Precedence can be used by a superior authority within the Security
Authority to permit partial delegation of access control policy setting
within an ACSA. This can be achieved by the superior authority setting a
general policy at a high precedence and authorizing users representing
the subordinate authority (e.g. associated with an ACIA) to create and
modify ACI with a lower precedence, in order to tailor the general
policy for specific purposes. The partial delegation thus requires the
means for the superior authority to limit the maximum precedence that
the subordinate authority can assign to ACI under its control.

Limiting the maximum precedence that can be used by a subordinate
authority is outside the scope of this ISP and must be done by local
means.

## 6.11 Access Controls and Shadowing {#access-controls-and-shadowing .unnumbered}

If a DSA that supports Access Controls allows shadowing of any portion
of its DIT, the shadowing agreement shall state that the shadow consumer
supports the same level of access control and will only allow access to
that information in accordance with the access control policy pertaining
to the information.

A DSA supporting access controls, that acts as a shadow consumer to
another portion of the DIT, should only shadow information, if the DSA
is able to support the access control policy of the shadowed
information. Administrative authorities have a duty to ensure that the
recipients of shadowed information have the means of carrying out access
control for the specified level, or they should not accept shadowing
agreements that require access cntrol beyond the DSA's capability.

For an example shadowing agreement template refer to ADY62.

\<Ed. note: I did not see a template in ADY62 yet, but it seems that
this would be the most appropriate ISP to contain one.\>

######## 

**(Normative)**

# Profile Requirements List {#profile-requirements-list .Annex .unnumbered}

In the event of a discrepancy becoming apparent in the body of
autonomous DSA procedures and the tables in this Annex, this Annex is to
take precedence.

# Introduction {#introduction-1 .Annex-1}

This annex specifies the constraints and characteristics on what shall
or may appear in an implementor's PICS for an implementation conformant
to this part of ISO/IEC ISP 15125. This annex identifies restrictions
placed by this part of the ISP on the corresponding base specification
requirements.

This PRL addresses features required for the support of Simple Access
Control (SAC) and Basic Access Control by a DSA in a DAP or DSP
association. As such it only addresses those features needed to support
access control. When filling in the PICS Proforma this PRL must be
combined with the PRL found in ISO/IEC ISP 15125-3 (ADY 21) and ISO/IEC
ISP 15125-6 (ADY 42) for DAP associations and/or ISO/IEC ISP 15125-4
(ADY 22) and ISO/IEC ISP 15125-7 (ADY 43) for DSP associations. This PRL
shall take precedence for like features.

# Identification of the Implementation {#identification-of-the-implementation .Annex-1}

## Identification of the PICS {#identification-of-the-pics .Annex-2}

For access control of a DAP association this part of the ISP is based on
ITU-T Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997, *Information
technology \-- Open Systems Interconnection -Directory Access Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma* ICS
tables.

For access control of a DSP association this part of the ISP is based on
ITU-T Recommendation X.584 (1997) \| ISO/IEC 13248-2: 1997, *Information
technology \-- Open Systems Interconnection -Directory System Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma* ICS
tables.

The tables in this Annex, while not necessarily following the same
numbering as the corresponding PICS tables, carry the same title.

This PRL must be combined with ISO/IEC ISP 15125-3 for DAP associations
and/or ISO/IEC ISP 15125-4 for DSP associations to properly complete the
PICS. Support for elements in this PRL should be used in place of those
same items found in ISO/IEC ISP 15125-3 and ISO/IEC ISP 15125-4.
Implementations compliant with this part of the ISP should show support,
based on this part of the ISP, in the PICS.

The DAP PICS covers all aspects of the DAP protocol, which is a broader
scope than covered in this part of the ISP. Implementations showing
support for this part of the ISP should address the following ICS
tables:

-   All general ICS tables (i.e. those tables that are not associated
    with a DUA or DSA). These are tables that do not delineate support
    for DUAs and DSAs. (PICS clause A.3, A.4, A.5, and subclause A.6.1)

-   ICS tables that are included in a clause associated with a DSA.
    (PICS subclause A.6.2.1)

-   The DSA support column for ICS tables that delineate between DUAs
    and DSAs support.

The DSP PICS covers all aspects of the DSP protocol, which is a broader
scope than covered in this part of the ISP. Implementations showing
support for this part of the ISP should address the following ICS
tables:

-   All general ICS tables (PICS clause A.3, A.4, A.5, and subclauses
    A.6.1 and A.6.2)

-   The support columns for ICS tables delineate between DSA roles
    (initiator, relay, and responder). Tables in the PRL associated with
    the DSP protocol shall apply to all roles for which the
    implementation is claiming compliance.

# Instructions  {#instructions .Annex-1}

## Purpose and structure of the PRL {#purpose-and-structure-of-the-prl .Annex-2}

The purpose of this PRL is to provide supplier's of implementations to
the ITU-T Recommendations X.500 (1993) \| International Standards
ISO/IEC 9594:1995 with a consistent expression of restrictions to the
corresponding PICS proforma based on this part of the ISP.

The PRL is in the form of a set of items. An item is provided for each
capability for which an implementation choice is allowed. Items are also
provided for mandatory capabilities for which no implementation choice
is allowed. Each item includes an item number, item description, a
protocol status value (which reflects the base specification
requirements as expressed in the PICS), a profile status value (which
reflects restrictions to the PICS imposed by this part of the ISP), a
predicate column (which predicates are set or employed by the profile),
and profile note column.

This clause provides general information and instructions for completion
of the proforma.

Subclause A.3 contains the DAP PRL tables.

Subclause A.4 contains the DSP PRL tables

Subclause B.1 is for the identification of the technical corrigenda to
this part of the ISP.

## Symbols, terms, and abbreviations {#symbols-terms-and-abbreviations .Annex-2}

### Introduction {#introduction-2 .Annex-3}

Notations have been introduced in order to reduce the size of the tables
in the PRL. These have allowed the use of multi-column layout where the
columns are headed 'Protocol Status' and 'Profile Status'. Definitions
of each are given below. Additionally, the following definitions apply:

protocol status (value): An allowed entry in the status column for an
item in a PICS proforma table;

profile status (value): An allowed entry in the status column for an
item in a PRL table which reflects restrictions imposed by this part of
the ISP;

### Prerequisite notation {#prerequisite-notation .Annex-3}

If a predicate applies to a whole table, a prerequisite line may be
specified in front of the table to which it applies. A prerequisite line
takes the form:

Prerequisite: \<Predicate\>

The meaning of such a line is that if \<predicate\> is True, then the
table applies, else it is not applicable.

### Item reference numbers {#item-reference-numbers .Annex-3}

Each line within the PRL is numbered at the left-hand edge of the line.
This numbering is included as a means of uniquely identifying all
possible implementation details within the PRL. This referencing should
be consistent with the corresponding PICS item reference.

The means of referencing individual responses is done by the following
sequence:

\- a reference to the smallest enclosing the relevant item;

\- a solidus character, \'/\';

\- the reference number of the row in which the response appears;

\- if, and only if, more than one response occurs in the row identified
by the reference number, then each possible entry is implicitly labeled
a, b, c, etc. from left to right, and this letter is appended to the
sequence.

An example of the use of this notation would be A.4.3.3.4/1, which
refers to the support for CompareArgument in a Compare protocol data
unit.

### Protocol Status column {#protocol-status-column .Annex-3}

This column indicates the level of support required for conformance to
this ITU-T \| ISO/IEC standard, as expressed in the PICS.

The values are as follows:

> m the capability is required to be implemented, in conformance with
> the related specification;
>
> o the capability may be implemented, and if it is implemented it is
> required to conform to the related specification
>
> c the requirement on the capability depends on the selection of other
> optional or conditional items;
>
> i the capability is outside the scope of the PICS, and hence
> irrelevant and not subject to conformance testing;
>
> \- in the given context it is impossible to use this capability.

Nested conditionals are denoted by nested numbering (e.g. 1, 1.1, 1.1.1,
etc.) of the item descriptions in the tables. A table may have zero, one
or more levels of nesting. The status of a leading item is specified by
its status entry, as defined above. The status of a subordinate (that is
nested) item is specified as follows: If the superior item is supported,
the status of the subordinate item is determined by its status column
entry and applicable predicate, if any. If the superior item is not
supported, the subordinate item is not applicable, independent of its
status column entry.

> Note: It is possible to label conditional and optional status items
> (usually by use of a number). For the purpose of the PRL, in order to
> avoid confusion between the Protocol Status and Profile Status
> numbering, conditional and optional numbering as expressed in the
> PICS, and associated Protocol Status column, is dropped. The notation
> is instead replaced with 'cn' and 'o.n' to reflect that the PICS
> conditional and optional items have associated numbers.

### Profile Status column {#profile-status-column .Annex-3}

This column indicates the level of support required for conformance to
this part of the ISP.

The values are as follows:

> m the capability is required to be implemented, in conformance with
> the related specification;
>
> o the capability may be implemented, and if it is implemented it is
> required to conform to the related specification
>
> c the requirement on the capability depends on the selection of other
> optional or conditional items;
>
> i the capability is outside the scope of this part of the ISP, and
> hence irrelevant and not subject to conformance testing;
>
> \- in the given context it is impossible to use this capability.

Nested conditionals are denoted by nested numbering (e.g. 1, 1.1, 1.1.1,
etc.) of the item descriptions in the tables. A table may have zero, one
or more levels of nesting. The status of a leading item is specified by
its status entry, as defined above. The status of a subordinate (that is
nested) item is specified as follows: If the superior item is supported,
the status of the subordinate item is determined by its status column
entry and applicable predicate, if any. If the superior item is not
supported, the subordinate item is not applicable, independent of its
status column entry.

### Predicate column {#predicate-column .Annex-3}

The item number contained in the predicate column, if any, means that
the status in the \"Profile Status\" column applies only when the PRL
states that one or more features identified by the item is supported.

### Predicate Name {#predicate-name .Annex-3}

The predicate name indicates that name upon which the predicate is
based. A predicate name flagged with an asterisk preceding the predicate
name indicates the condition by which the predicate is being set. A
predicate name not flagged with an asterisk indicates the predicate on
which the conditional support is based.

### Note column {#note-column .Annex-3}

This column indicates the following:

> Note xx - refers to Note xx;
>
> See xx - refers to Table xx.
>
> See Part xx - refers to another part of the ISO/IEC ISP 15125
> associated with the element.

Information entered into this column applies to the PRL and the Profile
Status column. These notes may also have meaning to the Protocol Status
column, however, notes specific to the Protocol Status column are found
in the PICS.

# PRL Tables for DAP Association {#prl-tables-for-dap-association .Annex-1}

These tables reflect restrictions to the base specification imposed by
this part of the ISP. Not all of the DAP PICS tables are listed in this
PRL, but instead just those deemed necessary to reflect the PRL.

The PRL tables reflect support for items which are different than that
found in ISO/IEC ISP 15125-3 (ADY 21) and ISO/IEC ISP 15125-6 (FDY 42).
For consistency the item numbering follow numbering for the same item
for the ISO/IEC ISP 15125-3 and ISO/IEC ISP 15125-6 PRL. Tables will
therefore show gaps in numbering and will not necessarily start with the
number one.

Cross-references to the corresponding PICS tables are supplied in the
table title. For instance "Ref. A.6.3.3.1.1" would refer to table
A.6.3.3.1.1 of Appendix A in the PICS.

Implementers should submit completed PICS based on guidance expressed in
above

Predicates set in clause A.4, PRL Tables for DAP Association, are only
meaningful for this section. They do not transfer to clause A.5, PRL
Tables for DSP Association.

Prior to completing the PICS based on this PRL, the Profile Specific
Implementation Conformance Statement (ICS) found in Annex B of this
document should first be filled out. [The Profile Specific ICS sets
predicates that are used by this PRL]{.underline}. Implementors should
therefore first address clause A.4.2 (General Capabilities and Global
statement of conformance) below because this clause sets predicates used
in Annex B. Implementors should next address the Profile Specific ICS in
Annex B which sets predicates used throughout the rest of this PRL

## Roles Ref. A.6.1 {#roles-ref.-a.6.1 .Annex-2}

No additional requirements beyond those specified in ISO/IEC ISP
15125-3.

## General Capabilities and Global statement of conformance {#general-capabilities-and-global-statement-of-conformance .Annex-2}

Non-supported mandatory capabilities are to be identified in the PICS,
with an explanation of why the implementation is non-conformant. Such
information shall be provided in subclause A.6.6 \"Other Information\"
of the PICS.

### General Capabilities Ref. A.6.2.2.1 {#general-capabilities-ref.-a.6.2.2.1 .Annex-3}

No additional requirements beyond those specified in ISO/IEC ISP
15125-3.

### Supported Security Levels Ref. A.6.2.2.2 {#supported-security-levels-ref.-a.6.2.2.2 .Annex-3}

+------+-------------------------------+----+----+-----------+-------+
| Item | Question                      | Pr | P  | Predicate | Note  |
| No.  |                               | ot | ro | Name      |       |
|      |                               | oc | fi |           |       |
|      |                               | ol | le |           |       |
|      |                               |    |    |           |       |
|      |                               | St | St |           |       |
|      |                               | at | at |           |       |
|      |                               | us | us |           |       |
+======+===============================+====+====+===========+=======+
| 2    | simple                        | o  | m  |           | See   |
|      |                               | .n |    |           | Part  |
|      |                               |    |    |           | 6     |
+------+-------------------------------+----+----+-----------+-------+
| 3    | strong                        | o  | m  |           | See   |
|      |                               | .n |    |           | Part  |
|      |                               |    |    |           | 6     |
+------+-------------------------------+----+----+-----------+-------+

### Supported Access Control Schemes Ref. A.6.2.2.3 {#supported-access-control-schemes-ref.-a.6.2.2.3 .Annex-3}

+-----+--------------------------------+----+----+----------+-------+
| I   | Access Control Scheme          | Pr | P  | P        | Note  |
| tem |                                | ot | ro | redicate |       |
| No. |                                | oc | fi | Name     |       |
|     |                                | ol | le |          |       |
|     |                                |    |    |          |       |
|     |                                | St | St |          |       |
|     |                                | at | at |          |       |
|     |                                | us | us |          |       |
+=====+================================+====+====+==========+=======+
| 1   | Simplified Access Control      | o  | o  |          |       |
|     |                                |    | .1 |          |       |
+-----+--------------------------------+----+----+----------+-------+
| 2   | Basic Access Control           | o  | o  | \        |       |
|     |                                |    | .1 | *BAC-DSA |       |
+-----+--------------------------------+----+----+----------+-------+
| 3   | Other                          | i  | i  |          |       |
+-----+--------------------------------+----+----+----------+-------+

o.1 The DSA must support at least one of SAC or BAC to be conformant to
this part of the ISP.

## Capabilities and options.  {#capabilities-and-options. .Annex-2}

This part of the ISP identifies the supported application context, the
PDUs and operations.

The operation arguments and PDU parameters are identified.

### Supported application context.  {#supported-application-context. .Annex-3}

The only application context supported is Directory Access application
context.

### Operations and extensions {#operations-and-extensions .Annex-3}

#### Operations Ref. A.6.3.2.1 {#operations-ref.-a.6.3.2.1 .Annex-4}

No additional requirements beyond those specified in ISO/IEC ISP
15125-3.

Note that this part of the ISP only addresses access control.

#### Extensions Ref. A.6.3.2.2 {#extensions-ref.-a.6.3.2.2 .Annex-4}

DSAs should conform as a precondition to ISO/IEC 15125-3 (ADY 21).
Extensions should be consistent with support found in ISO/IEC 15125-3.

+-----+------------------+-------+------+-------------+-------------+
| I   | Extension        | Pro   | Pro  | Predicate   | Note        |
| tem |                  | tocol | file | Name        |             |
| No. |                  |       |      |             |             |
|     |                  | S     | St   |             |             |
|     |                  | tatus | atus |             |             |
+=====+==================+=======+======+=============+=============+
| 1   | subentries       | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+

###  {#section-1 .Annex-3 .unnumbered}

### Protocol Elements {#protocol-elements .Annex-3}

#### Access Control Ref. A.6.3.3.24 {#access-control-ref.-a.6.3.3.24 .Annex-4}

##### Access Control Information Ref. A.6.3.3.24.1 {#access-control-information-ref.-a.6.3.3.24.1 .Annex-5}

+-----+------------------+------+---+------+-------------+-------------+
| I   | Protocol Element | Prot | P |      | Predicate   | Note        |
| tem |                  | ocol | r |      | Name        |             |
| No. |                  |      | o |      |             |             |
|     |                  | St   | f |      |             |             |
|     |                  | atus | i |      |             |             |
|     |                  |      | l |      |             |             |
|     |                  |      | e |      |             |             |
|     |                  |      |   |      |             |             |
|     |                  |      | S |      |             |             |
|     |                  |      | t |      |             |             |
|     |                  |      | a |      |             |             |
|     |                  |      | t |      |             |             |
|     |                  |      | u |      |             |             |
|     |                  |      | s |      |             |             |
+=====+==================+======+===+======+=============+=============+
| 1   | ACIItem          | o    |   | m    |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.1 | i                | c:m  |   | m    |             |             |
|     | dentificationTag |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.2 | precedence       | c:m  |   | m    |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.3 | aut              | c:m  |   | m    |             |             |
|     | henticationLevel |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | basicLevels      | c:m  |   | m    |             |             |
| 3.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | level            | c    |   | m    |             |             |
| .3. |                  | :o.n |   |      |             |             |
| 1.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | localQualifier   | c    |   | o    |             |             |
| .3. |                  | :o.n |   |      |             |             |
| 1.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | other            | i    |   | i    |             |             |
| 3.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | itemOrUserFirst  | c:m  |   | m    |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | itemFirst        | c    |   | m    |             |             |
| 4.1 |                  | :o.n |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | protectedItems   | c:m  |   | m    |             | See         |
| .4. |                  |      |   |      |             | A.4.3.3.1.2 |
| 1.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | itemPermissions  | c:m  |   | m    |             |             |
| .4. |                  |      |   |      |             |             |
| 1.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | precedence       | c:o  |   | m    |             | d(1.2)      |
| .1. |                  |      |   |      |             |             |
| 2.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | userClasses      | c:m  |   | m    |             | See         |
| .1. |                  |      |   |      |             | A.4.3.3.1.3 |
| 2.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | grantsAndDenials | c:m  |   | m    |             | See         |
| .1. |                  |      |   |      |             | A.4.3.3.1.4 |
| 2.3 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | userFirst        | c    |   | m    |             |             |
| 4.2 |                  | :o.7 |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | userClasses      | c:m  |   | m    |             | See         |
| .4. |                  |      |   |      |             | A.4.3.3.1.3 |
| 2.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | userPermissions  | c:m  |   | m    |             |             |
| .4. |                  |      |   |      |             |             |
| 2.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | precedence       | c:o  |   | m    |             | d(1.2)      |
| .2. |                  |      |   |      |             |             |
| 2.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | protectedItems   | c:m  |   | m    |             | See         |
| .2. |                  |      |   |      |             | A.4.3.3.1.2 |
| 2.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | grantsAndDenials | c:m  |   | m    |             | See         |
| .2. |                  |      |   |      |             | A.4.3.3.1.4 |
| 2.3 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+

##### Protected Items Ref. A.6.3.3.24.2 {#protected-items-ref.-a.6.3.3.24.2 .Annex-5}

+-----+------------------+-------+------+--------------+-------------+
| I   | Protocol Element | Pro   | Pro  | Predicate    | Note        |
| tem |                  | tocol | file | Name         |             |
| No. |                  |       |      |              |             |
|     |                  | S     | St   |              |             |
|     |                  | tatus | atus |              |             |
+=====+==================+=======+======+==============+=============+
| 1   | entry            | o     | m    |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 2   | allUs            | o     | m    |              |             |
|     | erAttributeTypes |       |      |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 3   | attributeType    | o     | m    |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 4   | al               | o     | o    |              |             |
|     | lAttributeValues |       |      |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 5   | allUserAttri     | o     | o    |              |             |
|     | buteTypes&Values |       |      |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 6   | attributeValue   | o     | o    |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 7   | selfValue        | o     | o    |              |             |
+-----+------------------+-------+------+--------------+-------------+

##### User Classes Ref. A.6.3.3.24.3 {#user-classes-ref.-a.6.3.3.24.3 .Annex-5}

+-----+------------------+-------+------+-------------+-------------+
| I   | Protocol Element | Pro   | Pro  | Predicate   | Note        |
| tem |                  | tocol | file | Name        |             |
| No. |                  |       |      |             |             |
|     |                  | S     | St   |             |             |
|     |                  | tatus | atus |             |             |
+=====+==================+=======+======+=============+=============+
| 1   | allUsers         | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 2   | thisEntry        | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 3   | name             | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 4   | userGroup        | o     | o    | \*userGroup |             |
+-----+------------------+-------+------+-------------+-------------+
| 5   | subtree          | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+

##### Grants and Denials Ref. A.6.3.3.24.4 {#grants-and-denials-ref.-a.6.3.3.24.4 .Annex-5}

**\< Editors note: Support for all grants and denial is mandatory in the
base PICS, therefore they are all mandatory in this ISP. \>**

+----+-------------------+-------+------+-------------+-------------+
| It | Protocol Element  | Pro   | Pro  | Predicate   | Note        |
| em |                   | tocol | file | Name        |             |
| N  |                   |       |      |             |             |
| o. |                   | S     | St   |             |             |
|    |                   | tatus | atus |             |             |
+====+===================+=======+======+=============+=============+
| 1  | grantAdd          | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 2  | denyAdd           | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 3  | gra               | m     | m    |             |             |
|    | ntDiscloseOnError |       |      |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 4  | de                | m     | m    |             |             |
|    | nyDiscloseOnError |       |      |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 5  | grantRead         | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 6  | denyRead          | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 7  | grantRemove       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 8  | denyRemove        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 9  | grantBrowse       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 10 | denyBrowse        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 11 | grantExport       | m     | c2   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 12 | denyExport        | m     | c2   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 13 | grantImport       | m     | c3   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 14 | denyImport        | m     | c3   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 15 | grantModify       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 16 | denyModify        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 17 | grantRename       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 18 | denyRename        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 19 | grantReturnDN     | m     | c4   |             | Note 1      |
+----+-------------------+-------+------+-------------+-------------+
| 20 | denyReturnDN      | m     | c4   |             | Note 1      |
+----+-------------------+-------+------+-------------+-------------+
| 21 | grantCompare      | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 22 | denyCompare       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 23 | grantFilterMatch  | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 24 | denyFilterMatch   | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+

c2: If \[exportEntry\] then support of this feature is m else -.

c3: If \[importEntry\] then support of this feature is m else -.

c4: If \[returnDNEntry\] then support of this feature is m else -.

Note 1: If returnDN is supported and the DN is not to be returned,
either the entry may be omitted from a search result, or, an operational
attribute may be created and populated with the DN that an
administrative domain wishes to insert in a search or read result. Or
some other equivalent mechanism can be used which should be noted in the
PICS.

##### Subtree Specification Ref. A.6.3.3.24.5 {#subtree-specification-ref.-a.6.3.3.24.5 .Annex-5}

\<ed note: subtree support is covered in ADY61 for access control\>

### Directory Schema {#directory-schema .Annex-3}

#### Standard Object Classes Ref. A.6.4.1.1 {#standard-object-classes-ref.-a.6.4.1.1 .Annex-4}

Prerequisite: \[userGroup\]

+------+------------------+-------+------+-------------+-------------+
| Item | Object Class     | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 10   | groupOfNames     | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 11   | gr               | o     | m    |             |             |
|      | oupOfUniqueNames |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+

#### Attribute Types Ref. A.6.4.3.1 {#attribute-types-ref.-a.6.4.3.1 .Annex-4}

Prerequisite: \[userGroup\]

+------+------------------+-------+------+-------------+-------------+
| Item | Attribute Type   | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 1    | member           | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 2    | uniqueMember     | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+

#### Matching Rules Ref. A.6.4.4 {#matching-rules-ref.-a.6.4.4 .Annex-4}

Prerequisite: \[userGroup\]

+------+------------------+-------+------+-------------+-------------+
| Item | Matching Rule    | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 1    | caseIgnoreMatch  | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 22   | u                | o     | m    |             |             |
|      | niqueMemberMatch |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+

### Information Framework {#information-framework .Annex-3}

#### Information Framework Object Classes Ref. A.6.4.6.1 {#information-framework-object-classes-ref.-a.6.4.6.1 .Annex-4}

+------+------------------+-------+------+-------------+-------------+
| Item | Object Class     | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 1    | subentry         | m     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 2    | acces            | cn    | m    |             |             |
|      | sControlSubentry |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+

### Access Control {#access-control .Annex-3}

#### Access Control Attributes Ref. A.6.4.8.2 {#access-control-attributes-ref.-a.6.4.8.2 .Annex-4}

+------+------------------+-------+------+-------------+-------------+
| Item | Attribute        | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 1    | acc              | m     | m    |             |             |
|      | essControlScheme |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+
| 2    | prescriptiveACI  | m     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 3    | entryACI         | cn    | c1   |             |             |
+------+------------------+-------+------+-------------+-------------+
| 4    | subentryACI      | m     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+

c1: If \[BAC-DSA\] then support of this feature is m else o.

# PRL Tables for DSP Association {#prl-tables-for-dsp-association .Annex-1}

These tables reflect restrictions to the base specification imposed by
this part of the ISP. Not all of the DSP PICS tables are listed in this
PRL, but instead just those deemed necessary to reflect the PRL.

The PRL tables reflect support for items which are different than that
found in ISO/IEC ISP 15125-4 (ADY 22) and ISO/IEC ISP 15125-7 (FDY 43).
For consistency the item numbering follow numbering for the same item
for the ISO/IEC ISP 15125-4 and ISO/IEC ISP 15125-7 PRL. Tables will
therefore show gaps in numbering and will not necessarily start with the
number one.

Cross-references to the corresponding PICS tables are supplied in the
table title. For instance "Ref. A.6.3.3.1.1" would refer to table
A.6.3.3.1.1 of Appendix A in the PICS.

Implementers should submit completed PICS based on guidance expressed in
above

Predicates set in clause A.5, PRL Tables for DSP Association, are only
meaningful for this section. They do not transfer to clause A.4, PRL
Tables for DAP Association.

Prior to completing the PICS based on this PRL, the Profile Specific
Implementation Conformance Statement (ICS) found in Annex B of this
document should first be filled out. [The Profile Specific ICS sets
predicates that are used by this PRL]{.underline}. Implementors should
therefore first address clause A.4.2 (General Capabilities and Global
statement of conformance) below because this clause sets predicates used
in Annex B. Implementors should next address the Profile Specific ICS in
Annex B which sets predicates used throughout the rest of this PRL

## Roles Ref. A.6.1 {#roles-ref.-a.6.1-1 .Annex-2}

No additional requirements beyond those specified in ISO/IEC ISP
15125-4.

## General Capabilities and Global statement of conformance {#general-capabilities-and-global-statement-of-conformance-1 .Annex-2}

Non-supported mandatory capabilities are to be identified in the PICS,
with an explanation of why the implementation is non-conformant. Such
information shall be provided in subclause A.6.5 \"Other Information\"
of the PICS.

### General Capabilities Ref. A.6.2.1 {#general-capabilities-ref.-a.6.2.1 .Annex-3}

No additional requirements beyond those specified in ISO/IEC ISP
15125-4.

### Supported Security Levels Ref. A.6.2.2 {#supported-security-levels-ref.-a.6.2.2 .Annex-3}

+------+-------------------------------+----+----+-----------+-------+
| Item | Question                      | Pr | P  | Predicate | Note  |
| No.  |                               | ot | ro | Name      |       |
|      |                               | oc | fi |           |       |
|      |                               | ol | le |           |       |
|      |                               |    |    |           |       |
|      |                               | St | St |           |       |
|      |                               | at | at |           |       |
|      |                               | us | us |           |       |
+======+===============================+====+====+===========+=======+
| 2    | simple                        | o  | m  |           | See   |
|      |                               | .n |    |           | Part  |
|      |                               |    |    |           | 7     |
+------+-------------------------------+----+----+-----------+-------+
| 3    | strong                        | o  | m  |           | See   |
|      |                               | .n |    |           | Part  |
|      |                               |    |    |           | 7     |
+------+-------------------------------+----+----+-----------+-------+

### Supported Access Control Schemes Ref. A.6.2.3 {#supported-access-control-schemes-ref.-a.6.2.3 .Annex-3}

+-----+--------------------------------+----+----+----------+-------+
| I   | Access Control Scheme          | Pr | P  | P        | Note  |
| tem |                                | ot | ro | redicate |       |
| No. |                                | oc | fi | Name     |       |
|     |                                | ol | le |          |       |
|     |                                |    |    |          |       |
|     |                                | St | St |          |       |
|     |                                | at | at |          |       |
|     |                                | us | us |          |       |
+=====+================================+====+====+==========+=======+
| 1   | Simplified Access Control      | o  | o  |          |       |
|     |                                |    | .1 |          |       |
+-----+--------------------------------+----+----+----------+-------+
| 2   | Basic Access Control           | o  | o  | \        |       |
|     |                                |    | .1 | *BAC-DSA |       |
+-----+--------------------------------+----+----+----------+-------+
| 3   | Other                          | i  | i  |          |       |
+-----+--------------------------------+----+----+----------+-------+

o.1 The DSA must support at least one of SAC or BAC to be conformant to
this part of the ISP.

## Capabilities and options.  {#capabilities-and-options.-1 .Annex-2}

This part of the ISP identifies the supported application context, the
PDUs and operations.

The operation arguments and PDU parameters are identified.

### Supported application context.  {#supported-application-context.-1 .Annex-3}

The only application context supported is Directory System application
context.

### Operations and extensions {#operations-and-extensions-1 .Annex-3}

#### Operations Ref. A.6.3.2.1 {#operations-ref.-a.6.3.2.1-1 .Annex-4}

No additional requirements beyond those specified in ISO/IEC ISP 15125-4
(ADY 22).

Note that this part of the ISP only addresses access control.

#### Extensions Ref. A.6.3.2.2 {#extensions-ref.-a.6.3.2.2-1 .Annex-4}

DSAs should conform as a precondition to ISO/IEC 15125-4 (ADY 22).
Extensions should be consistent with support found in ISO/IEC 15125-3.

+-----+------------------+-------+------+-------------+-------------+
| I   | Extension        | Pro   | Pro  | Predicate   | Note        |
| tem |                  | tocol | file | Name        |             |
| No. |                  |       |      |             |             |
|     |                  | S     | St   |             |             |
|     |                  | tatus | atus |             |             |
+=====+==================+=======+======+=============+=============+
| 1   | subentries       | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+

###  {#section-2 .Annex-3 .unnumbered}

### Protocol Elements {#protocol-elements-1 .Annex-3}

#### Access Control Ref. A.6.3.3.29 {#access-control-ref.-a.6.3.3.29 .Annex-4}

##### Access Control Information Ref. A.6.3.3.29.1 {#access-control-information-ref.-a.6.3.3.29.1 .Annex-5}

+-----+------------------+------+---+------+-------------+-------------+
| I   | Protocol Element | Prot | P |      | Predicate   | Note        |
| tem |                  | ocol | r |      | Name        |             |
| No. |                  |      | o |      |             |             |
|     |                  | St   | f |      |             |             |
|     |                  | atus | i |      |             |             |
|     |                  |      | l |      |             |             |
|     |                  |      | e |      |             |             |
|     |                  |      |   |      |             |             |
|     |                  |      | S |      |             |             |
|     |                  |      | t |      |             |             |
|     |                  |      | a |      |             |             |
|     |                  |      | t |      |             |             |
|     |                  |      | u |      |             |             |
|     |                  |      | s |      |             |             |
+=====+==================+======+===+======+=============+=============+
| 1   | ACIItem          | cn   |   | m    |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.1 | i                | c:m  |   | m    |             |             |
|     | dentificationTag |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.2 | precedence       | c:m  |   | m    |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.3 | aut              | c:m  |   | m    |             |             |
|     | henticationLevel |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | basicLevels      | c:m  |   | m    |             |             |
| 3.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | level            | c:m  |   | m    |             |             |
| .3. |                  |      |   |      |             |             |
| 1.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | localQualifier   | c:o  |   | o    |             |             |
| .3. |                  |      |   |      |             |             |
| 1.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | other            | i    |   | i    |             |             |
| 3.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | itemOrUserFirst  | c:m  |   | m    |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | itemFirst        | c:m  |   | m    |             |             |
| 4.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | protectedItems   | c:m  |   | m    |             | See         |
| .4. |                  |      |   |      |             | A.5.3.3.1.2 |
| 1.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | itemPermissions  | c:m  |   | m    |             |             |
| .4. |                  |      |   |      |             |             |
| 1.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | precedence       | c:o  |   | m    |             | d(1.2)      |
| .1. |                  |      |   |      |             |             |
| 2.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | userClasses      | c:0  |   | m    |             | See         |
| .1. |                  |      |   |      |             | A.5.3.3.1.3 |
| 2.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | grantsAndDenials | c:m  |   | m    |             | See         |
| .1. |                  |      |   |      |             | A.5.3.3.1.4 |
| 2.3 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.  | userFirst        | c:m  |   | m    |             |             |
| 4.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | userClasses      | c:o  |   | m    |             | See         |
| .4. |                  |      |   |      |             | A.5.3.3.1.3 |
| 2.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1   | userPermissions  | c:m  |   | m    |             |             |
| .4. |                  |      |   |      |             |             |
| 2.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | precedence       | c:o  |   | m    |             | d(1.2)      |
| .2. |                  |      |   |      |             |             |
| 2.1 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | protectedItems   | c:m  |   | m    |             | A.5.3.3.1.2 |
| .2. |                  |      |   |      |             |             |
| 2.2 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+
| 1.4 | grantsAndDenials | c:m  |   | m    |             | See         |
| .2. |                  |      |   |      |             | A.5.3.3.1.4 |
| 2.3 |                  |      |   |      |             |             |
+-----+------------------+------+---+------+-------------+-------------+

##### Protected Items Ref. A.6.3.3.24.2 {#protected-items-ref.-a.6.3.3.24.2-1 .Annex-5}

+-----+------------------+-------+------+--------------+-------------+
| I   | Protocol Element | Pro   | Pro  | Predicate    | Note        |
| tem |                  | tocol | file | Name         |             |
| No. |                  |       |      |              |             |
|     |                  | S     | St   |              |             |
|     |                  | tatus | atus |              |             |
+=====+==================+=======+======+==============+=============+
| 1   | entry            | o     | m    |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 2   | allUs            | o     | m    |              |             |
|     | erAttributeTypes |       |      |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 3   | attributeType    | o     | m    |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 4   | al               | o     | o    |              |             |
|     | lAttributeValues |       |      |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 5   | allUserAttri     | o     | o    |              |             |
|     | buteTypes&Values |       |      |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 6   | attributeValue   | o     | o    |              |             |
+-----+------------------+-------+------+--------------+-------------+
| 7   | selfValue        | o     | o    |              |             |
+-----+------------------+-------+------+--------------+-------------+

##### User Classes Ref. A.6.3.3.24.3 {#user-classes-ref.-a.6.3.3.24.3-1 .Annex-5}

+-----+------------------+-------+------+-------------+-------------+
| I   | Protocol Element | Pro   | Pro  | Predicate   | Note        |
| tem |                  | tocol | file | Name        |             |
| No. |                  |       |      |             |             |
|     |                  | S     | St   |             |             |
|     |                  | tatus | atus |             |             |
+=====+==================+=======+======+=============+=============+
| 1   | allUsers         | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 2   | thisEntry        | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 3   | name             | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+
| 4   | userGroup        | o     | o    | \*userGroup |             |
+-----+------------------+-------+------+-------------+-------------+
| 5   | subtree          | o     | m    |             |             |
+-----+------------------+-------+------+-------------+-------------+

##### Grants and Denials Ref. A.6.3.3.24.4 {#grants-and-denials-ref.-a.6.3.3.24.4-1 .Annex-5}

**\< Editors note: Support for all grants and denial is mandatory in the
base PICS, therefore they are all mandatory in this ISP. \>**

+----+-------------------+-------+------+-------------+-------------+
| It | Protocol Element  | Pro   | Pro  | Predicate   | Note        |
| em |                   | tocol | file | Name        |             |
| N  |                   |       |      |             |             |
| o. |                   | S     | St   |             |             |
|    |                   | tatus | atus |             |             |
+====+===================+=======+======+=============+=============+
| 1  | grantAdd          | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 2  | denyAdd           | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 3  | gra               | m     | m    |             |             |
|    | ntDiscloseOnError |       |      |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 4  | de                | m     | m    |             |             |
|    | nyDiscloseOnError |       |      |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 5  | grantRead         | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 6  | denyRead          | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 7  | grantRemove       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 8  | denyRemove        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 9  | grantBrowse       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 10 | denyBrowse        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 11 | grantExport       | m     | c2   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 12 | denyExport        | m     | c2   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 13 | grantImport       | m     | c3   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 14 | denyImport        | m     | c3   |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 15 | grantModify       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 16 | denyModify        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 17 | grantRename       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 18 | denyRename        | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 19 | grantReturnDN     | m     | c4   |             | Note 1      |
+----+-------------------+-------+------+-------------+-------------+
| 20 | denyReturnDN      | m     | c4   |             | Note 1      |
+----+-------------------+-------+------+-------------+-------------+
| 21 | grantCompare      | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 22 | denyCompare       | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 23 | grantFilterMatch  | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+
| 24 | denyFilterMatch   | m     | m    |             |             |
+----+-------------------+-------+------+-------------+-------------+

c2: If \[exportEntry\] then support of this feature is m else -.

c3: If \[importEntry\] then support of this feature is m else -.

c4: If \[returnDNEntry\] then support of this feature is m else -.

Note 1: If returnDN is supported and the DN is not to be returned,
either the entry may be omitted from a search result, or, an operational
attribute may be created and populated with the DN that an
administrative domain wishes to insert in a search or read result. Or
some other equivalent mechanism can be used which should be noted in the
PICS.

##### Subtree Specification Ref. A.6.3.3.24.5 {#subtree-specification-ref.-a.6.3.3.24.5-1 .Annex-5}

\<ed note: subtree support is covered in ADY61 for access control\>

### Directory Schema {#directory-schema-1 .Annex-3}

#### Standard Object Classes Ref. A.6.4.1.1 {#standard-object-classes-ref.-a.6.4.1.1-1 .Annex-4}

Prerequisite: \[userGroup\]

+------+------------------+-------+------+-------------+-------------+
| Item | Object Class     | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 10   | groupOfNames     | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 11   | gr               | o     | m    |             |             |
|      | oupOfUniqueNames |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+

#### Attribute Types Ref. A.6.4.3.1 {#attribute-types-ref.-a.6.4.3.1-1 .Annex-4}

Prerequisite: \[userGroup\]

+------+------------------+-------+------+-------------+-------------+
| Item | Attribute Type   | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 42   | member           | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 43   | uniqueMember     | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+

#### Matching Rules Ref. A.6.4.4 {#matching-rules-ref.-a.6.4.4-1 .Annex-4}

Prerequisite: \[userGroup\]

+------+------------------+-------+------+-------------+-------------+
| Item | Matching Rule    | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 1    | caseIgnoreMatch  | o     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 22   | u                | o     | m    |             |             |
|      | niqueMemberMatch |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+

### Information Framework {#information-framework-1 .Annex-3}

#### Information Framework Object Classes Ref. A.6.4.6.1 {#information-framework-object-classes-ref.-a.6.4.6.1-1 .Annex-4}

+------+------------------+-------+------+-------------+-------------+
| Item | Object Class     | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 1    | subentry         | m     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 2    | acces            | cn    | m    |             |             |
|      | sControlSubentry |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+

### Access Control {#access-control-1 .Annex-3}

#### Access Control Attributes Ref. A.6.4.8.2 {#access-control-attributes-ref.-a.6.4.8.2-1 .Annex-4}

+------+------------------+-------+------+-------------+-------------+
| Item | Attribute        | Pro   | Pro  | Predicate   | Notes       |
| No.  |                  | tocol | file | Name        |             |
|      |                  |       |      |             |             |
|      |                  | S     | St   |             |             |
|      |                  | tatus | atus |             |             |
+------+------------------+-------+------+-------------+-------------+
| 1    | acc              | m     | m    |             |             |
|      | essControlScheme |       |      |             |             |
+------+------------------+-------+------+-------------+-------------+
| 2    | prescriptiveACI  | m     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+
| 3    | entryACI         | cn    | c1   |             |             |
+------+------------------+-------+------+-------------+-------------+
| 4    | subentryACI      | m     | m    |             |             |
+------+------------------+-------+------+-------------+-------------+

c1: If \[BAC-DSA\] then support of this feature is m else o.

######## [^2])Annex B

# (Normative) {#normative .Annex .unnumbered}

# Profile Specific Implementation Conformance Statement {#profile-specific-implementation-conformance-statement .Annex .unnumbered}

# Introduction {#introduction-3 .Annex-1}

Implementations claiming support to ISO/IEC 15125-9 should include this
Profile Specific Implementation Conformance Statement (PSICS) with ITU-T
Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997, *Information
technology \-- Open Systems Interconnection -Directory Access Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma* and/or
ITU-T Recommendation X.584 (1997) \| ISO/IEC 13248-2: 1997, *Information
technology \-- Open Systems Interconnection -Directory System Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma*. This
annex sets predicates, which are necessary to determine the proper
support for elements of the PRL tables found in annex A, and should
therefore be addressed prior to filling out the PICS.

The proper submittal of this PSICS shall be based on guidance given in
ITU-T Recommendation X.583 (1997) \| ISO/IEC 13248-1: 1997, *Information
technology \-- Open Systems Interconnection -Directory Access Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma* and/or
ITU-T Recommendation X.584 (1997) \| ISO/IEC 13248-2: 1997, *Information
technology \-- Open Systems Interconnection -Directory System Protocol:
Protocol Implementation Conformance Statement (PICS) Proforma*.

# Identification of the Profile Corrigenda {#identification-of-the-profile-corrigenda .Annex-1}

The supplier of the PICS proforma shall identify any corrigenda (i.e.
Technical Corrigenda or equivalent) to the published ISP that have been
applied. Suppliers of the proforma should modify the proforma, or attach
relevant additional pages in order to apply the corrigenda, and then
record the application of the profile corrigenda in the PICS tables.

+---------------------+------------------------------------------------+
| Identification of   | ISO/IEC 15125-9                                |
| corrigenda applied  |                                                |
| to this part of the | Corr:                                          |
| ISP                 |                                                |
|                     | Corr:                                          |
|                     |                                                |
|                     | Corr:                                          |
|                     |                                                |
|                     | Corr:                                          |
+---------------------+------------------------------------------------+

# Access Support {#access-support .Annex-1}

+-----+-----------------------------+----+----+------+---------+----+
| I   | Operation                   | Pr | P  | Sup  | Pr      | N  |
| tem |                             | ot | ro | port | edicate | ot |
| No. |                             | oc | fi |      | Name    | es |
|     |                             | ol | le |      |         |    |
|     |                             |    |    |      |         |    |
|     |                             | St | St |      |         |    |
|     |                             | at | at |      |         |    |
|     |                             | us | us |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 1   | Does the DSA support Read   | o  | m  |      |         |    |
|     | for entry access?           |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 2   | Does the DSA support Browse | o  | m  |      |         |    |
|     | for entry access?           |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 3   | Does the DSA support Add    | o  | m  |      |         |    |
|     | for entry access?           |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 4   | Does the DSA support Modify | o  | m  |      |         |    |
|     | for entry access?           |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 5   | Does the DSA support Remove | o  | m  |      |         |    |
|     | for entry access?           |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 6   | Does the DSA support Rename | o  | m  |      |         |    |
|     | for entry access?           |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 7   | Does the DSA support Import | o  | o  |      | \*impo  |    |
|     | for entry access?           |    |    |      | rtEntry |    |
+-----+-----------------------------+----+----+------+---------+----+
| 8   | Does the DSA support Export | o  | o  |      | \*expo  |    |
|     | for entry access?           |    |    |      | rtEntry |    |
+-----+-----------------------------+----+----+------+---------+----+
| 9   | Does the DSA support        | o  | o  |      | \       |    |
|     | ReturnDN for entry access?  |    |    |      | *return |    |
|     |                             |    |    |      | DNEntry |    |
+-----+-----------------------------+----+----+------+---------+----+
| 10  | Does the DSA support        | o  | m  |      |         |    |
|     | DiscloseOnError for entry   |    |    |      |         |    |
|     | access?                     |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 11  | Does the DSA support Read   | o  | m  |      |         |    |
|     | for attribute access?       |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 12  | Does the DSA support        | o  | m  |      |         |    |
|     | Compare for attribute       |    |    |      |         |    |
|     | access?                     |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 13  | Does the DSA support        | o  | m  |      |         |    |
|     | FilterMatch for attribute   |    |    |      |         |    |
|     | access?                     |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 14  | Does the DSA support Add    | o  | m  |      |         |    |
|     | for attribute access?       |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 15  | Does the DSA support Remove | o  | m  |      |         |    |
|     | for attribute access?       |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+
| 16  | Does the DSA support        | o  | m  |      |         |    |
|     | DiscloseOnError for         |    |    |      |         |    |
|     | attribute access?           |    |    |      |         |    |
+-----+-----------------------------+----+----+------+---------+----+

[^1]: Part 8 (ADY 44) DSA Simple Access Control, in the taxonomy, was
    combined with part 9 (ADY 45) to form a single profile on Access
    Control. Part 8 therefore does not exist.

[^2]: Copyright release for ICS proformas: Users of this
    Recommendation/International Standard may freely reproduce this ICS
    proforma so that it can be used for its intended purpose and may
    further publish the completed ICS.