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 [page ]

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."

Level of Assurance (LoA)

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.

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.

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].

[INSERT DIAGRAM]

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.