Difference between revisions of "Security & Privacy DAM"
| Line 2: | Line 2: | ||
[[Security|Back to Security Main Page]] | [[Security|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== | ==Authority== | ||
| Line 8: | Line 11: | ||
====Issues==== | ====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)== | ==Level of Assurance (LoA)== | ||
| Line 31: | Line 47: | ||
=Grantee= | =Grantee= | ||
| + | Grantee seems to merge concept of Grantor as well. Suggest disambiguating and adding Grantor class. | ||
===S&P DAM R1 Description [page 25]=== | ===S&P DAM R1 Description [page 25]=== | ||
| − | + | 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. | ||
| + | ''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]. | ||
| − | === | + | ===S&P DAM R1 Description [page 25]=== |
Revision as of 21:30, 21 February 2013
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 [page 23]
page 23 Class: AuthorizationPolicy 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.
Issues
Grantee
Grantee seems to merge concept of Grantor as well. Suggest disambiguating and adding Grantor class.
S&P DAM R1 Description [page 25]
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.
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].
