schacUserPrivateAttribute

A short description

Privacy requirements, as expressed by the user and/or the organizational policies.

Usage

Utility class
[ Core | Standard | Extended ]
Basic applications like white pages and some authorization data.

Is attribute required?
Optional. Application selects whether it will support attribute or not.

Confidentiality
Low. Data well known from other sources.

Integrity
High. Values are required to be up to date, maximum 24 hours latency.

Availability
High. If the LDAP uses this attribute, it should as far as possible be provided for all. relevant objects. Authorization will fail if no value is available.

Details

Multiple values?
Multivalued

Value format
An attribute type identifier

Attribute origin
shac

LDAP

OID

1.3.6.1.4.1.25178.1.2.18

Datatype

An attribute type identifier

« Back to view list of all attributes

Used to model privacy requirements, as expressed by the user and/or the organizational policies. The values are intended to be attribute type names and applies to the attribute and any subtypes of it for a given entity.
In what respects to data exchange, it applies to the expression of privacy requirements.
This attribute can also have specific operational semantics (one has already been applied to LDAP servers: see references below), that will be defined in a separate document. This attribute applies to the person entry. Use. e.g. for white pages information where a user does not want his contact details to be displayed. Make sure that access to the private attributes are constricted in the LDAP e.g. by use of access control listis.

Attributes listed in this attribute should not be exposed externally.

Feide usage notes

The Feide login service, Moria, may need access to all attributes for its own use, but will not forward to the service provider those attributes marked as private by the user. Possible consequences of marking an attribute as private include that a service provider will not receive sufficient information for authorizing access to resources, or the service offering may be limited. E.g. if the user will not reveal his email address, a service cannot offer information delivered through email.

The decision to hide attributes is done by the individual user, and the host organization should ensure that users have sufficient information about possible consequences of making attributes private.

If the directory is available to other applications or clients, the method used for realizing the proper access control is a local matter. The software in use may lack mechanisms for sufficiently fine-grained access control. A consequence may be that the host organization must choose either to refuse LDAP access for (non-trusted) applications/clients or to allow such access but inform their users about the limited protection of private attributes.