|
|
| Line 27: |
Line 27: |
| | | | |
| | ===Issues=== | | ===Issues=== |
| − | Is LoA limited to assurance about the reliability of a user/initiator's credentials as the DAM suggests? LoA is commonly thought of as associated with credentials, and is focused on "the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued." See[http://gforge.hl7.org/gf/download/docmanfileversion/7190/10054/HL7LOABillBraithwaite092012.pptx Levels of Assurance Bill Braithwaite]
| |
| − |
| |
| − | However, ISO 10181-3:1996 concept of LoA seems to apply to a more inclusive set of security elements (initiator/user, target/resource, request, and context) and the assurance that their security label bindings trustworthy. ISO 10181-3:1996 references the binding of Access Control Information (ACI) in several places, e.g., Section 5.2.2.4 [page 17] 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.
| |
| − |
| |
| | | | |
| | =Grantee= | | =Grantee= |
Revision as of 17:28, 20 February 2013
Back to Security Main Page
Authority
S&P DAM R1 Description [page ]
Issues
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
S&P DAM R1 Description [page ]
Issues
