[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
Hi John I am happy with your 5 access modes as described below, and note that I am only talking about mode c) BTG and the other modes are out of scope of the BTG discussion. With this clarification, can we now agree that we are all talking about mode c) and that in particular modes d) and e) are not cases of BTG. More comments below On 02/12/2010 15:37, Davis, John M. wrote: > 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”: It is not clear if YYY is a single rule or a set of rules comprising an overall policy. > > Domain A POLICY: It is not clear if this is policy YYY or if YYY is different to this. 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”). For the case of BTG, it would be clearer if this was separated into two rule, the first of which can then be ignored in the BTG discussion since as you point out later this is not a case of BTG. 1. Grant Initiator access to Domain A objects with Target sensitivity attribute=”X” IFF Initiator role=”Y” and Initiator sensitivity attribute = “X”. 2. Grant Initiator access to Domain A objects with Target sensitivity attribute=”X” IFF Initiator role=”Y” and BTG Warning=”Yes”. So if we accept that rule 2 is the only rule of interest, then I will tell you how we have implemented exactly the same thing, using a different rule set 2a Kent. Grant Initiator access to Domain A objects with Target sensitivity attribute=”X” IFF Initiator role=”Y” and BTG State =”Glass Broken”. 2b Kent. Grant Initiator BTG access to Domain A objects with Target sensitivity attribute=”X” IFF Initiator role=”Y” On grant return obligations "notify manager, write to audit trail etc as determined by application". > > 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 possessthe Initiator sensitivity attribute “VIP” (or > better) then access is granted(this is NOT BTG), > > 5.If the user does not possessthe “VIP” attribute, then theaccess > 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?). In your implementation this exception will need to be specifically defined so that the application knows to throw the BTG banner for this exception, and not for other exceptions. So you have a standardisation issue here. In our implementation the access control system returns the BTG result, which is why we want to standardise the BTG result. The application now knows to show the BTG banner because the authz decision was BTG. > > 6.The user accepts the warning=”Yes”. > > 7.The request is resubmitted this time with the attribute BTG > warning=”Yes”(this is BTG). In your implementation the PEP has changed the BTG state from BTG warning=No to BTG warning =Yes. This means that the application has to know what the state variable is (BTG warning) that is known by the PDP, and this could vary from application to application unless it is standardised. What we want to achieve is that the authz infrastructure changes the BTG state so that the application does not need to. The application code then does not need to know what the BTG state variable is, which to my mind, is a good thing for application writers and portability. So in our implementation, the application now asks the authz infrastructure if the user can perform the BTG operation. This of course is granted by Rule 2b Kent, and the BTG state is changed to Glass Broken by the authz infrastructure. The BTG related obligations from Rule 2b kent are now returned to the application for it to enforce. It does not appear that your implementation has such a feature (at least you have not described it) but this is surely essential. Once the obligations have been enforced the application then repeats the initial access request, which is now granted by Rule 2a Kent because the BTG state has been updated to Glass Broken. > > 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 proposedBTG Permission (can accessVIP Segment > objectswhere 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. Agreed step 4 is not BTG therefore I suggest we simply scrub it from the description since it is not relevant. > > 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. In my terminology it is "user choice to perform the break the glass operation" which is equivalent to actually breaking the glass next to a hotel firedoor. To conclude, we both have very similar notions of what BTG is, but the differences are 1. Your method requires a standard BTG exception to be returned by the access control system, whereas our method requires a standard BTG response to be returned. It would be best if the standard way is backwards compatible with existing non-BTG implementations and reverts to a simple Deny in the case where the application does not support BTG. Rich's proposed way of doing this, sending a Deny with a new standardised BTG obligation appears to satisfy the backwards compatibility issue and is XACML version independent. Would this be acceptable to you 2. Your method requires the application to maintain the BTG state, to know what it is, how to update it, and when to return it in an access decision request. Our method requires the application to know what the standard BTG operation is and to request this when the user requests to break the glass. I have a proposal for this below. Our method supports either the context handler/PIP infrastructure storing the BTG state and updating it or the PDP storing the BTG state and updating it. It does not preclude the application from doing this as well (as in your method), but in this case no standardisation of the BTG operation is needed, since it is the performing of the BTG operation that causes the BTG state to change. 3. Your method does not appear to support the returning of obligations when the glass is broken by the user. Our method does. PROPOSAL FOR STANDARDISING THE BTG OPERATION. 1. We standardise the BTG obligation that is used to signal the BTG response 2. This BTG obligation has an additional optional attribute assignment which is called BTG request context. 3. When a user attempts to access a BTG protected resource using request context <access resource>, the access control system returns a DENY response with the BTG obligation. 4. The application sees the BTG obligation and shows the BTG screen to the user. 5. If the user decides to break the glass, the application either a. If the BTG obligation does not contain the BTG request context attribute assignment, the application does its own thing, updates the BTG state etc, and then repeats the request context <access resource> but sets the BTG state to true this time. Access is now granted. b. If the BTG obligation does contain the BTG request context, the PEP sends this to the access control system. Note that the PEP only needs to copy over what it has been given and does not need to know or understand any of the parameters. It is up to the access control system to fill in this BTG request context in whatever way it sees fit. The access control system returns granted with an optional set of obligations that should be enforced. The PEP enforces these obligations then repeats the request context <access resource> to the access control system. Access is now granted. regards David > > 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 30, 2010 12:34 AM > To: Moehrke, John (GE Healthcare) > Cc: xacml > Subject: Re: [xacml] Draft BTG Profile > > 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 > -- ***************************************************************** 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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]