[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Draft BTG Profile
David, Updated the previous discussion and
BTG with editorial corrections, additional definitions and linkage to “data
segmentation”. 1. We have agreed BTG is
defined by mode c. 2.
We still (in my mind) need to expand the profile discussion beyond the single
attribute of user role to a broader view of sensitivity attributes
applicable to segmentation. This is the general case, providing a flexible
capability to deal with a broader range of policies beside role attributes and
to decide and enforce attribute based access control based upon segmentation
and BTG. Access
Control System Modes The following modes of access control system operation are defined
based upon possession or lack of possession of access control attributes. a) those who have permission to access the resource (e.g., ANY permission that grants access) b) those who are denied access to the resource (e.g., possess NO permission for the resource) c) those who are normally denied access but may choose to BTG and
gain access if they deem it appropriate (e.g. they break the barrier by
"choice" rather than by asserting any further/special permissions). d) those who are normally denied access but may gain access
by elevating privilege e) Bypass. Insecure system state in which access control
decision/enforcement is intentionally disabled or circumvented by authorized
users. Note 1: 1. Regarding
"Bypass/override". This vocabulary is overloaded with Canada using
it (as I recall) equivalent to BTG. A distinctly different meaning of
bypass is a maintenance/programming mode (in which the system is purposely
placed in a non-secure state circumventing security controls). : BTG
USE CASE Example BTG Use Case illustrating both mode a) and c) above: Definitions: ·
Access Control Information (ACI). Any information used for
access control purposes, including contextual information. ISO 10181-3
Access Control defines classes of access control ACI. Classes of access
control decision information (ACI) include: Initiator, Target, Access
request, Operand, Contextual, Initiator-bound, Target-bound, Access-request
bound. ·
Access Control Decision Information (ADI). The portion
(possibly all) of the ACI made available to the Access Control Decision
Function in making a particular access control decision. ISO 10181-3 ·
Attribute – Characteristic of a subject, resource, action or
environment that may be referenced in a predicate (attribute statement that can
be evaluated) or target. OASIS eXtensible Access Control Markup Language
(XACML) ·
Permission. An approval to perform an operation on one or more
RBAC protected objects. . ANSI-INCITS 359-2004 ·
Security Domain. A set of users, a set of protected
objects and the security policy that binds the two. ISO/IEC 15816 (ITU X.841) ·
Segment (General). A subset of the information objects
within a security domain whose members share one or more access control
decision information attributes (e.g. all records with Target ADI=”VIP”, all
records with Contextual ADI=”Psychiatric Ward”, all records with Target bound
ADI=”Care Team AND patient record =”Smith”). ·
Segment (HITECH). A subset of specific and sensitive
individually identifiable health information within a security domain whose
members share one or more access control decision information attributes. ·
Target. The set of decision requests, identified by
definitions for resource, subject and action, that a rule, policy or policy set
is intended to evaluate. OASIS eXtensible Access Control Markup Language
(XACML) Action: User (initiator) operates in Domain A and has
proper permissions/roles to perform assigned tasks. In the course of
activities, this user desires to search for a record within a defined VIP
segment of Domain A under a purpose of use = “XXX” and Domain A policy=”YYY”: Domain A POLICY: Grant Initiator access to Domain A
objects with Target sensitivity attribute=”X” IFF Initiator role=”Y” and
(Initiator sensitivity attribute = “X” OR BTG Warning=”Yes”). Note 1: Access to most domain data is obtained with role
Y=”Clinician” and target sensitivity attribute = “Null”, however VIP records
are marked with Sensitivity attribute = “VIP” and therefore the user must
either already hold this attribute or assert the BTG Warning attribute at
runtime. 1.
The user authenticates and accesses the system using the
“Clinician” role suitable for the purpose of use of “Treatment”.
2.
S/He searches for a record 3.
The record has Target attribute=VIP. 4.
If the user possess the Initiator sensitivity attribute “VIP”
(or better) then access is granted (this is NOT BTG), 5.
If the user does not possess the “VIP” attribute, then the
access control system throws an exception which causes the application to
present the user with the BTG warning banner (e.g., Acknowledge understanding
that your activities will be audited, supervisor will be notified, etc do you
accept YES/NO?). 6.
The user accepts the warning=”Yes”. 7.
The request is resubmitted this time with the attribute BTG
warning=”Yes” (this is BTG). 8.
The access control system grants access (re-evaluates the policy
including the run-time BTG warning acknowledgement which is now present). Note 2: Possession of the sensitivity attribute (STEP 4)
is functionally equivalent to the proposed BTG Permission (can access VIP
Segment objects where permission operation=”access” and protected object=”VIP
Segment Objects”) and presumes a pre-existing authorization attribute.
Asserting an authorization attribute already held is NOT BTG. Note 3: Lack of any authorization attribute specific to the
segmented data and the user “Choice” to accept the BTG Warning is the key
element of BTG that distinguishes it from other access modes. Annex
A HITECH Data Segmentation Provisions HITECH Provision Directing
Consideration of Data Segmentation ‘‘SEC. 3002. HIT POLICY COMMITTEE. ‘‘(a) ESTABLISHMENT.—There
is established a HIT Policy Committee to make policy recommendations to the
National Coordinator relating to the implementation of a nationwide health
information technology infrastructure,
including implementation of the strategic plan described in section 3001(c)(3).
‘‘(b) DUTIES.— ‘‘(1) RECOMMENDATIONS ON HEALTH INFORMATION TECHNOLOGY INFRASTRUCTURE.—The HIT Policy Committee shall recommend a policy
framework for the development and adoption of a nationwide health information
technology infrastructure that permits the electronic exchange and use of
health information as is consistent with the strategic plan under section 3001(c)(3) and that includes
the recommendations under paragraph (2). The Committee shall update such
recommendations and make new recommendations as appropriate. ‘‘(2) SPECIFIC AREAS OF STANDARD DEVELOPMENT.— ‘‘(A) IN GENERAL.—The
HIT Policy Committee shall recommend the areas in which standards,
implementation specifications, and certification criteria are needed for
the electronic exchange and use of health information for purposes
of adoption under section 3004 and shall recommend an order of priority
for the development, harmonization, and recognition of such standards,
specifications, and certification criteria among the areas so
recommended. Such standards and implementation specifications shall
include named standards, architectures, and software schemes for
the authentication and security of individually identifiable health
information and other information as needed to ensure the reproducible
development of common solutions across disparate entities. ‘‘(B) AREAS REQUIRED FOR CONSIDERATION.—For purposes of
subparagraph (A), the HIT Policy Committee shall make
recommendations for at least the following areas: ‘‘(i)
Technologies that protect the privacy of health information
and promote security in a qualified electronic health
record, including for the segmentation and protection from
disclosure of specific and
sensitive individually
identifiable health information with the goal of minimizing
the reluctance of patients to seek care (or disclose
information about a condition) because of privacy concerns,
in accordance with applicable law, and for the use and
disclosure of limited data sets of such information.
‘‘(8) CONSIDERATION.—The National Coordinator shall ensure that the relevant and
available recommendations and comments from the National
Committee on Vital and Health Statistics are considered in the
development of policies. Link to NCVHS Privacy
Recommendations 2006-2008 (combined ) http://www.ncvhs.hhs.gov/privacyreport0608.pdf Regards, Mike Davis, CISSP Department of Veterans Affairs Office of Health Information Security Architect 760-632-0294 From: Davis, John M. David, Thanks for the comments and
lively discussion. Below are some follow-on definitions and an
example…intended to clarify security concepts involved more than call up
specific XACML mechanisms. 1. Regarding
"Bypass/override". This vocabulary is overloaded with Canada
using it (as I recall) equivalent to BTG. A distinctly different meaning
of bypass that I’m more familiar with is a maintenance/programming mode (in
which the system is purposely placed in a non-secure state circumventing
security controls). Adding this to the list of access modes: a) those who have permission to
access the resource (e.g., ANY permission that grants access) b) those who are denied access
to the resource (e.g., possess NO permission for the resource) c) those who are normally
denied access but may choose to BTG and gain access if they deem it
appropriate (e.g. they break the barrier by "choice" not by
asserting any further/special permissions). d) those who are normally
denied access but may gain access by elevating privilege e) Bypass. Insecure
system state in which access control decision/enforcement is intentionally
disabled or circumvented by authorized users. 2. Here is a example BTG
Use Case illustrating Case c above: BTG
USE CASE Definitions: ·
Security Domain. A set of users, a set of protected
objects and the security policy that binds the two. ·
Access Control Decision Information (ACI). ISO 10181-3
Access Control defines classes of access control ACI. Classes of access
control decision information (ACI) include: Initiator, Target, Access
request, Operand, Contextural, Initiator-bound, Target-bound, Access-request
bound. ·
Permission. Per ANSI-INCITS 359-2004
a Permission is an approval to perform an operation
on one or more RBAC protected objects. user (initiator) operates in Domain A and has proper
permissions/roles to perform assigned tasks. In the course of activities,
this user desires to search for a record within a defined VIP segment of Domain
A under a purpose of use = “XXX” and Domain A policy=”YYY”: Domain A POLICY: Grant Initiator access to Domain A objects
with Target sensitivity attribute=”X” IFF Initiator role=”Y” and (Initiator
sensitivity attribute = “X” OR BTG Warning=”Yes”). Note 1: Access to most domain data is obtained with role
Y=”Clinician” and target sensitivity attribute = “Null”, however VIP records
are marked with Sensitivity attribute = “VIP” and therefore the user must
either already hold this attribute or assert the BTG Warning attribute at
runtime. 9.
The user authenticates and accesses the system using the
“Clinician” role suitable for the purpose of use of “Treatment”.
10.
S/He searches for a record 11.
The record has Target attribute=VIP. 12.
If the user possess the Initiator sensitivity attribute “VIP”
(or better) then access is granted (this is NOT BTG), 13.
If the user does not possess the “VIP” attribute, then the
access control system throws an exception which causes the application to
present the user with the BTG warning banner (e.g., Acknowledge understanding
that your activities will be audited, supervisor will be notified, etc do you
accept YES/NO?). 14.
The user accepts the warning=”Yes”. 15.
The request is resubmitted this time with the attribute BTG
warning=”Yes” (this is BTG). 16.
The access control system grants access (re-evaluates the policy
including the run-time BTG warning acknowledgement which is now present). Note 2: Possession of the sensitivity attribute (STEP 4)
is functionally equivalent to the proposed BTG Permission (can access VIP
Segment objects where permission operation=”access” and protected object=”VIP
Segment Objects”) and presumes a pre-existing authorization attribute.
Asserting an authorization attribute already held is NOT BTG. Note 3: Lack of any authorization attribute specific to the segmented
data and the user “Choice” to accept the BTG Warning is the key element of BTG
that distinguishes it from other access modes. Regards, Mike Davis, CISSP Department of Veterans Affairs Office of Health Information Security Architect 760-632-0294 -----Original Message----- Hi John In an earlier posting John Davis identified 4 use cases,
which are worth repeating again here a) those who have permission to access the resource
(e.g., ANY permission that grants access) b) those who are denied access to the resource (e.g.,
possess NO permission for the resource) c) those who are normally denied access but may choose to
BTG and gain access if they deem it appropriate (e.g. they break the
barrier by "choice" not by asserting any further/special
permissions). d) those who are normally denied access but may
gain access by elevating privilege We both agree that c) is BTG, but we still dont agree on
the mechanism; specifically, whether a permission to perform the BTG
action is needed or not. I believe in the general case it is, John
believes it is not and that it can be implied by context. There is also the issue of whether overriding access
control is a different use case to BTG or is the same as the BTG use
case above. I believe it is the same as the BTG use case. You believe
it is different. Therefore it would be good if you could add a fifth use
case to the above 4 which describes why override is different to
them. On 29/11/2010 17:24, Moehrke, John (GE Healthcare) wrote: > I agree with much of the sentiment that we need to
make sure we > understand the problem well before we solve it. I do
however believe > that we have multiple useful use-cases. Some
environments do indeed > want to have a permission that is only assigned to
senior clinicians > where they are privileged to override. I do agree
with Mike that this > should not be called BTG, as I agree with Mike that
we should be > consistent with our understanding of what BTG is vs
other use-cases. > We have tried to come up with just as catchy names
of these other > use-cases. > > Another aspect of these set of use-cases that I am
not seeing is that > in the case where a user override would allow
something, there is a > predicate communication that likely preceded
this. For example, how > did the clinician know that a document existed for
which they are > being denied access with an override possibility? A normal intuitive guess is one answer. Here is one
example of this. The doctor has a patient in A&E. The doctor looks up the
patient name in the DB, and then asks to read the patient record. This is
returned. He then asks to retrieve the DNA records (or other sensitive data
such as AIDS etc.) and is denied access with a BTG response. He enters
a reason (person is bleeding in A&E) and breaks the glass. He
is then granted access. We have another live demo example and test here https://authz.tas3.kent.ac.uk:8443/btg/ Typically this > predicate transaction needs also to understand that
access is > contingent on future state change. If the user could
not use an > override, then the predicate transaction should not
return the > result. (note that this is also regionally defined
in policy; as I do > know of regions/organizations that do want to tempt
their clinicians > with objects that they couldn't get access to at
all; whereas other > regions do not ever want to tempt their clinicians.) > > So, this is not just the use-case of the transaction
where BTG flag > would be submitted, but this also affects other
transactions too. I > don’t think this changes the potential solutions,
but does broaden > the description when we get around to that. this does indeed broaden the potential use cases
considerably if we are concerned with an action now that can effect another
action many steps down in a workflow. I must admit that we have not yet
considered such use cases regards David > > John > >> -----Original Message----- From: Davis, John M. >> [mailto:Mike.Davis@va.gov] Sent: Monday,
November 29, 2010 10:46 >> AM To: David Chadwick Cc: xacml Subject: RE:
[xacml] Draft BTG >> Profile >> >> David, >> >> I did not say that permissions were not
necessary, I said that two >> permissions were not necessary. I fully
appreciate the fact that >> the user has permissions regarding the protected
objects. This is >> clearly stated in the OASIS XSPA profiles of
XACML, SAML and >> WS-Trust, providing for both structural and
functional role >> attributes. >> >> XSPA also provides for purpose of use categories
to account for >> different "context" situations
including emergency access (commonly >> known as purpose of use). >> >> The fact that the user already has permission to
the data in the >> context of the purpose of use provides rationale
why additional >> permissions for break glass is unnecessary. Your
definition of BTG >> is actually closer to an "override" or
"Bypass" mode which is >> undesirable in real life. Perhaps you are
missing the concept that >> the user participates in many
"contexts" or purposes of use. To >> follow your rationale, a redundant BTG permission
would be required >> for each. >> >> In attempting to understand your profile and
concepts, we must >> start with defining them. I've provided mine
taken from an >> international SDO. Your terms
warrant a clear definition as >> well. >> >> Regards, Mike Davis, CISSP Department of
Veterans Affairs Office of >> Health Information Security Architect
760-632-0294 >> >> >> -----Original Message----- From: David Chadwick >> [mailto:d.w.chadwick@kent.ac.uk] Sent: Saturday,
November 27, 2010 >> 2:15 AM To: Davis, John M. Subject: Re: [xacml]
Draft BTG Profile >> >> Hi John >> >> Actually you misunderstood what I said about the
third class of >> user and wrongly inferred what the related
permissions were. In >> fact the third class of user (those allowed to
BTG) have TWO >> permissions associated with them and not just
one as you assumed. >> The first permission states "this class of
user is allowed access >> to the resource if the glass is broken" and
the second permission >> states "this class of user is allowed to
break the glass". By >> having these two permissions we achieve the
following effects: >> >> 1. This class of user is normally denied access
to the resource >> because the glass is not broken, and 2. This
class of user can >> decide if they want to break the glass or not,
and if they do >> decide to, then this action is granted to them.
Once they have >> taken this action, they then become entitled to
access the >> resource. >> >> Further responses are below >> >> On 26/11/2010 19:30, Davis, John M. wrote: >>> David, >>> >>> 1. Defining terms so that we are all on the
same page is very >>> important. >> >> I agree with this. This is why we have
standards. >> >> Also HL7 is an international SDO recognized by
ISO which >>> might be more useful to you than a single
hospital. My question >>> is regarding the following where you wrote: >>> >>> " c) those who are normally denied
access but may choose to BTG >>> and gain access if they deem it
appropriate." >>> >>> Simply changes the permissions asserted is
not BTG. If as the >>> BTG paper states a user already possesses a
"BTG permission", >>> then you are simply back to a variation of
a), e.g.: >>> >>> -User attempts to access using
"normal" permissions-access >>> denied -User chooses to assert "BTG
permission"-access granted >> >> Please see the fuller explanation above as to
why your >> interpretation is not correct >> >>> >>> Perhaps the application of " BTG
permission" invokes additional >>> response from the security system but if it
is still >>> fundamentally a permission which the user
already has which they >>> choose to apply in some context then it is
still case a). >>> >>> 2. The possibilities might be
clarified as follows: >>> >>> a) those who have permission to access the
resource (e.g., ANY >>> permission that grants access) b) those who
are denied access to >>> the resource (e.g., possess NO permission
for the resource) c) >>> those who are normally denied access but may
choose to BTG and >>> gain access if they deem it appropriate
(e.g. they break the >>> barrier by "choice" not by
asserting any further/special >>> permissions). d) those who are
normally denied access but may >>> gain access by elevating privilege (e.g. by: >>> >>> -Context (life threatening circumstance)
-Workflow (such as when >>> a user is granted addition privileges but
only within the context >>> of the workflow) -Other?) >> >> Yes I agree that there are these 4 different
classes of user. The >> BTG model we used only considered the first
three classes and did >> not consider d) above because we did not regard
this as a case of >> BTG. As you say, it is a case of elevating
privileges. (And this is >> nothing special or new, as operating systems
have had it for a long >> time e.g. a user who is both an administrator
and a normal user can >> gain root access by login out as a normal user
and logging in as >> administrator or by performing a switch user
command.) >> >> >>> >>> >>> 3. So in my VIP access case, users see
a "break glass barrier" >>> as a warning dialogue. They choose to
gain access by breaking >>> the glass on the barrier or they do
not. They don't need any >>> additional permissions to do either, they
"choose" the path. >> >> correct. We both agree on this from a user-view
perspective. >> >> I see no need for >>> nor any architectural advantage in the BTG
profile unless your >>> purpose is to provide an mechanism to
remotely BTG. >> >> Our purpose is the following: to implement BTG
in the application >> independent layer so that the application
dependent layer does not >> need to implement it. In this way we make it
very easy for all >> applications to support BTG. If you want all
applications to >> implement BTG in their own specific way, then
the profile we have >> proposed is not needed, since there is no BTG
standard needed. >> >> >> >> I propose that >>> this not as a BTG permission" so much
as a "promise" in response >>> to an BTG challenge presented as an
obligation. >> >> Sorry but I did not follow this sentence. Could
you be more >> explanatory please. >> >> >>> >>> 4. That said, my question to you
really goes back to the >>> definition of things. I'm suggesting
BTG may be an overloaded >>> term not universally shared and that a clear
definition would not >>> only be helpful but is imperative. >> >> I tend to agree with you on this last point. >> >> It is clear from our exchanges so far, that we
have had (and may >> still have) differing views on BTG. You saw your
emergency access >> example 2 below as a case of my BTG, whereas I
see it as a case of >> escalating privileges and not BTG. >> >> But by enumerating 4 cases as you did in 2.
above I think we now >> both agree on this classification >> >> regards >> >> David p.s. I note this was not sent to the XACML
list. Was this on >> purpose or not? I think it would be good to copy
them in on our >> exchanges >> >>> >>> Regards, Mike Davis, CISSP Department of
Veterans Affairs Office >>> of Health Information Security Architect
760-632-0294 >>> >>> >>> -----Original Message----- From: David
Chadwick >>> [mailto:d.w.chadwick@kent.ac.uk] Sent:
Thursday, November 25, >>> 2010 6:13 AM To: Davis, John M. Cc: xacml
Subject: Re: [xacml] >>> Draft BTG Profile >>> >>> Hi John >>> >>> thanks for your long explanation of the HL7
position. >>> >>> Our BTG work has been done in conjunction
with Porto's main >>> hospital in Portugal, along with the
University of Porto. So it >>> would appear that some Europeans at least
have a different >>> interpretation of BTG to the US work in HL7. >>> >>> We have published a number of papers on BTG
access in medical >>> situations and I will gladly send them to
you if you wish. >>> >>> The fundamental concept is this: >>> >>> 1. For any given resource, there are three
classes of user as >>> specified in the access control policy a)
those who have >>> permission to access the resource b) those
who are denied access >>> to the resource c) those who are normally
denied access but may >>> choose to BTG and gain access if they deem
it appropriate. >>> >>> I would say that class c) users exactly fit
your VIP record >>> access example below, and this is the class
of user who are being >>> dealt with in this profile. >>> >>> The profile is a generic profile and is not
tied to health care >>> resources. It can be used in any scenario
where they have the >>> above three classes of user >>> >>> regards >>> >>> David >>> >>> >>> On 23/11/2010 19:49, Davis, John M. wrote: >>>> David, >>>> >>>> 1. BTG is a common healthcare concept.
The Draft BTG profile >>>> seems to describe a concept somewhat
different. I've included a >>>> short paper which provides definitions,
descriptions and >>>> requirements for BTG and "emergency
access" as two distinct and >>>> different concepts within the healthcare
domain. Here is a >>>> short description from HL7's Access
Control Service Functional >>>> Model: >>>> >>>> /"Break‐glass is named after the
glass panel that protects a >>>> fire alarm. Everyone in the building is
authorized to use the >>>> fire alarm to report a fire, but the
ramifications of misuse >>>> are substantial. The fragile glass panel
is sufficient to avoid >>>> accidental triggering, and it forces the
user to stop and >>>> think/ >>>> >>>> /before acting. In the context of this
document, a “Break >>>> Glass” scenario involves a situation
where the access control >>>> policy will authorize the user to access
certain information or >>>> functionality, but only after the user
attests that one or more >>>> relevant conditions exist."/ >>>> >>>> 2. As described in the draft profile,
the most important >>>> concept is that the profile requires a
BTG permission. This >>>> does not match the notion of BTG as used
in healthcare which is >>>> much more like a user controlled
"gateway" much such as a fire >>>> alarm. I'll explain by means of a use
case: >>>> >>>> In this healthcare scenario, a user is
authorized to access >>>> patient records (has appropriate
permissions). Some records >>>> (e.g., VIP) are sequestered behind a BTG
barrier. A user >>>> attempting to access a VIP record will
be presented with a >>>> warning banner indicating that the
record is protected and that >>>> access will subject the user to
increased auditing (and perhaps >>>> other controls such as notifications to
system admins). In any >>>> case, the requester has two options; 1)
abort or 2) continue. >>>> If 2) is chosen the record is presented.
The distinguishing >>>> characteristic is that no elevation of
user permissions and no >>>> special "BTG permission" is
required, the user is already in >>>> the "clinician" group
authorized to view records. This is >>>> analogous to students in a high school.
They are all members of >>>> a group who are "authorized"
to pull the fire alarm. Doing so >>>> falsely will subject the student to
discipline but the student >>>> does not need the teachers authorization
to pull the alarm when >>>> conditions warrant. >>>> >>>> This is distinguished from emergency
access of the first kind >>>> (normal emergency room operations). In
emergency access #1, >>>> the context of the emergency
(significant harm or risk of death >>>> to the patient) needs to be presented so
that the access >>>> control system evaluates the appropriate
policy set (e.g. A >>>> clinician at one hospital may not be
authorized access to >>>> records at another under normal
conditions of “treatment”). In >>>> emergency access #1, the XSPA SAML attribute
assertion profile >>>> provides an "Emergency Access"
purpose of use attribute. This >>>> purpose of use allows the PDP to select
and evaluate the >>>> appropriate policy for the
"emergency" condition as opposed to >>>> normal "treatment". Again, it
is not the user permissions that >>>> are evaluated but the fundamental
context of the policy >>>> environment. >>>> >>>> There is emergency access of the second
kind which is a >>>> variation of emergency access #1. In
emergency access #2, the >>>> requester makes the request for
information under the purpose >>>> of use of treatment and clinical role.
Authorization to view >>>> the record under these conditions is
denied (perhaps an >>>> underlying privacy policy is being
enforced). In response the >>>> clinician responds by elevating
permissions by asserting the >>>> “emergency role” in the XSPA SAML
Assertion profile thereby >>>> elevating privileges under the same POU
of “treatment” and >>>> overriding the original policy decision.
In our work in HL7 we >>>> have found the “emergency”
role/permission unnecessary as POU >>>> has the added benefit of putting in
place (and managing) an >>>> emergency context vice a simple role.
Emergency #2 is probably >>>> closer to what is intended by the Draft
BTG profile but is >>>> significantly different from what is
described above. >>>> >>>> I believe additional discussion is
warranted on the >>>> fundamental concepts of the Draft BTG
profile, first to ensure >>>> common understanding of the different
forms of access, the uses >>>> of policy, purpose of use and permission
and second to >>>> establish sound use cases that will
sufficiently clarify the >>>> purpose and conditions under which use
of such a profile is >>>> warranted. >>>> >>>> Regards, Mike Davis, CISSP >>>> >>>> Department of Veterans Affairs >>>> >>>> Office of Health Information >>>> >>>> Security Architect >>>> >>>> 760-632-0294 >>>> >>>> -----Original Message----- From: David
Chadwick >>>> [mailto:d.w.chadwick@kent.ac.uk] Sent:
Tuesday, November 23, >>>> 2010 9:07 AM To: xacml Subject: [xacml]
Draft BTG Profile >>>> >>>> Dear List >>>> >>>> about a year ago we discussed the
standardisation of the Break >>>> The Glass response (see Seth Proctor's
message of 17 Dec 2009) >>>> and decided that a profile to
standardise the BTG response >>>> would be useful. Unfortunately Seth left
Sun before we got >>>> around to writing it. >>>> >>>> Consequently Stijn Lievens and myself
from Kent have produced >>>> a first version (attached) for your
consideration. I know its >>>> not in the correct format yet, but we
can fix that once the >>>> technical content has been agreed. >>>> >>>> Comments appreciated >>>> >>>> regards >>>> >>>> David >>>> >>>> -- >>>> >>>> >> **********************************************************
******* >>>> >>>> David W. Chadwick, BSc PhD >>>> >>>> Professor of Information Systems
Security School of Computing, >>>> University of Kent, Canterbury, CT2 7NF
Skype Name: >>>> davidwchadwick >>>> >>>> Tel: +44 1227 82 3221 >>>> >>>> Fax +44 1227 762 811 >>>> >>>> Mobile: +44 77 96 44 7184 >>>> >>>> Email: D.W.Chadwick@kent.ac.uk >>>> >>>> Home Page: >>>>
http://www.cs.kent.ac.uk/people/staff/dwc8/index.html >>>> >>>> Research Web site: >>>> http://www.cs.kent.ac.uk/research/groups/iss/index.html >>>> >>>> Entrust key validation string:
MLJ9-DU5T-HV8J PGP Key ID is >>>> 0xBC238DE5 >>>> >>>> >>
********************************************************** ******* >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> >> >>>> To unsubscribe from this mail list, you must leave the
OASIS TC that >>>> generates this mail. Follow this
link to all your TCs in >>>> OASIS at: https://www.oasis- >> open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>>> >> -- >> >>
********************************************************** ******* >> David W. Chadwick, BSc PhD Professor of
Information Systems >> Security School of Computing, University of Kent,
Canterbury, CT2 >> 7NF Skype Name: davidwchadwick Tel: +44 1227 82
3221 Fax +44 1227 >> 762 811 Mobile: +44 77 96 44 7184 Email:
D.W.Chadwick@kent.ac.uk >> Home Page:
http://www.cs.kent.ac.uk/people/staff/dwc8/index.html >> Research Web site: >> http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key >> validation string: MLJ9-DU5T-HV8J PGP Key ID is
0xBC238DE5 >> >>
********************************************************** ******* >> >> --------------------------------------------------------------------- >> >> To unsubscribe from this mail list, you must leave the
OASIS TC that >> generates this mail. Follow this link to
all your TCs in OASIS >> at: https://www.oasis- >>
open.org/apps/org/workgroup/portal/my_workgroups.php > > -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security School of Computing, University of Kent, Canterbury, CT2
7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page:
http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site:
http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the
OASIS TC that generates this mail. Follow this link to all your
TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Regards,
Mike Davis, CISSP Department
of Veterans Affairs Office
of Health Information Security
Architect 760-632-0294 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]