Security & Privacy DAM

Back to Security Main Page

Back to Security Main Page

Security and Privacy Dam R1(S&P DAM) Parking Lot for Errata

Purpose of this page is to document issues and questions about the S&P DAM, which may be addressed in a S&P DAM R2.

Authority

S&P DAM R1 Description

Issues

John Moerke: "If the group says that “Authority” is restricted to Jurisdictional and Provider Organizational; then just mark my comment non-persuasive. I personally believe that there are other ‘Authorities’, specifically the use of ‘Authority’ in the context of Privacy is not represented here."

Mike Davis: "I agree with John that patients have “Privacy authority” and that such authority exists, however, it only exits in context of jurisdictional and organizational policy as a subset (sounds like…hierarchy). There is no universal “privacy” context otherwise and in this sense the US HIPAA provides patients privacy authority for authorizations (disclosures) while leaving acceptance of such to the organization. Elsewhere in states, patient privacy is similarly handled in the context of jurisdictional policy. Propose the ontology of authority as: Jurisdictional (Global, Federal and state etc.), organizational, personal."

Kathleen Connor: "Suggest that we use PMAC policy authority and policy bridging. Patient has policy authority over patient's preferences. When that is bridged with the already bridged jurisdictional and organizational policies, the result is the patient's consent directive. This would align with S&P DAM description of the ConstraintPolicy Class [page 24]:

A constraint policy is intended to constrain an existing policy. For example, a ConstraintPolicy instance may be used to represent a privacy consent directive that sets specific ‘limitations’ on a default organizational policy regarding substance abuse data (e.g., 42 CFR Part 2). A policy (BasicPolicy or CompositePolicy) can be constrained by the use of profiles for tailoring a policy instance. Complex constraints (e.g., an OCL expression) may be applied and managed separately. For this definition and for management purposes, it is possible to separate externally-defined constraints and specify a 'ConstraintPolicy' with clearly defined associations to the constrained policy according to component model principles. Effectively, the result of applying constraints is just another CompositePolicy."

Grantee

Grantee seems to merge concept of Grantor as well. Suggest disambiguating and adding Grantor class.

S&P DAM R1 Description

Class: DelegationPolicy [page 25]: A delegation policy is intended to assign access rights to a specific individual or organization (a grantee). ISO 22600-2 defines delegation as 'conveyance of privilege from one entity that holds such privilege, to another entity'. A DelegationPolicy 'defines what authorizations can be delegated to whom'. Association 'DelegationPolicy.grantee' of type ' Grantee' with cardinality of [*] The person or organization that is the subject of delegation. This is the entity that receives the privilege granted by the DelegationPolicy.

Class: DelegationPolicy [page 25] A delegation policy is intended to assign access rights to a specific individual or organization (a grantee). ISO 22600-2 defines delegation as 'conveyance of privilege from one entity that holds such privilege, to another entity'. A DelegationPolicy 'defines what authorizations can be delegated to whom'. Association 'DelegationPolicy.grantee' of type ' Grantee' with cardinality of [*] The person or organization that is the subject of delegation. This is the entity that receives the privilege granted by the DelegationPolicy.

Level of Assurance (LoA)

Issues

Does Level of Assurance only apply to Initiator authentication and attribute ACI and not to target, request, and context ACI?

Kathleen pointed out 10810-3 discussion about assurance of the ACI bindings. Mike stated that LoA is term of art, and more specific than binding assurance because the "levels" for initiator credential LoA is quantified by authoritative sources such as NIST 800-632 and Kantara

Kathleen asked whether there is a term for this binding assurance that we can use in the DAM even though these might not have levels quantified by authoritative sources.

10810-3 [page 7] 5.2.2.4 Binding ACI to initiators, targets and access requests Binding ACI to an element (i.e. an initiator, target or access request) creates a secure linkage between an element and the ACI allocated to that element. The binding provides assurance to access control functions and other elements both that the ACI is indeed assigned to the particular element and that no modification has occurred since the binding was made. Binding is achieved by using an integrity service. Several binding mechanisms are possible, including some that are dependent on the location of the element and the ACI, while others may depend on some cryptographic signing or sealing process. The integrity of the binding of ACI to elements needs to be protected within initiator and target systems (e.g. by relying upon operating system functions such as file protection and process separation) and, also, in the exchange of ACI. Since there may be several possible representations of an element’s ACI (both within systems and between systems), different binding mechanisms may be used for the same ACI. Under some security policies, the confidentiality of ACI also needs to be maintained.

Initiator ACI; – a means to validate the binding of the access control certificate to a specific initiator so that it cannot be used by another initiator; Target ACI; "– a means to validate the binding of the access control certificate to a specific target so that it cannot be used to access another target;– a means to validate the binding of the access control certificate to a specific access request so that it cannot be used with another access request;

S&P DAM R1 Description

Class: AuthorizationPolicy [page 23]: AuthorizationPolicy is a specialization of a BasicPolicy and is used to describe an authorization policy that may be exchanged across domains. An instance of AuthorizationPolicy specifies 'permitted actions' according to ISO 22600-2. A positive (or negative) AuthorizationPolicy defines the actions ('OperationType') that a subject is permitted (or forbidden) to perform on a target. Actions encoded using the 'OperationType' class represents the operations defined in the interface of a target object. The following are attributes of an AuthorizationPolicy:

• Attribute 'AuthorizationPolicy.enable' of type ' Boolean' with cardinality of [1]

This attribute is used to specify if the policy enables or declines an authorization. If this attribute is set to 'true', the policy authorizes the actions and conditions pertaining to the resources referenced by the policy. Otherwise the authorization is declined.

• Attribute 'AuthorizationPolicy.levelOfAssurance' of type ' INT' with cardinality of [0..1]

Level of Assurance (LoA) refers to the degree of certainty that

• (1) a resource owner has that a person's physical self has been adequately verified before credentials are issued by a registration

authority, and

• (2) a user owns the credentials they are subsequently presenting to access the resource.

LoA is relevant to authentication, authorization, and access control. A BasicPolicy requires the level of assurance as indicated within the AuthorizationPolicy specialization.

Location/Workstation

Issues

Kathleen Connor: DAM R1 calls out “location/workstation” as an RBAC constraint and put a use case/policy specific limitations on the relation of a user to a location/workstation to a specific permission. Suggest that DAM R2 consolidate location and workstation as types of the context/environment class, 0…* of which may be components of a BasicPolicy, which looks like this [minus a lot of classes].

S&P DAM R1 Description

Class: Location [page 20]: Access may be granted only to initiators on specific end-user systems, workstations or terminals or only to initiators in a specific physical location. This class is required to support user authorization as specified by the business requirements (Security use case S.1). Association 'Location.providerOrganization' of type ' ProviderOrganization' with cardinality of [1] This association identifies the organization where the location is scoped. Attribute 'Location.workstationId' of type ' ST' with cardinality of [1] This attribute is used to specify the precise workstation used by an information user.

Privacy Policy

Issues

While there can be many Privacy Policies associated with a Consent Directive, and a Privacy Policy may be composed of many Privacy Rules, it's not clear that the many Privacy Rules composing a Consent Directive is a constraint on the superset of Privacy Rules from all the Privacy Polices with which the Consent Directive is associated. (Not sure if this is the correct interpretation of this diagram) There may be a need to create a "Composite Privacy Rule Set" rather than PrivacyRule as a component of Consent Directive.

S&P DAM R1 Description

Page 36: "a client's privacy consent represents a further constraint of default privacy policies applicable in that territory."