Author: Marlena Erdos

XACML notes:

Participants: Sekhar (Sun), Hal (Entegrity), Bill (self), Pierangela, Nishimura, Michiharu (IBM), Fred (Entitlenet), Simon (CrossLogix), Carlisle, Don (Hitachi), Joe (HP), Marlena (Tivoli), Phill (Verisign), Thomas.

Carlisle goes over Suresh & his use case Summary. Goal: "Kick start discussion".  "Eventually (this afternoon) derive requirements from these use cases."
[We go over each use case.]
HL 7 (HealthCare):
Fred: There is more that he'd submitted – it isn't in Carlisle's document.
Fred discusses his full set of information/cases.
HL 7 is directed to medical people.   Fred also made an XACML submission on Sept 4. 
Fred: HL 7 is proposing a standard for medical recoreds as XML documents.  They must satisfy needs in privacy – legally (HIPPA) and restricticted disclosure of information for medical reasons.  For example, sometimes doctors will withhold info from the patient, particularly in psychiatric cases.   Notably, the patient isn't the owner of data about him/herself.
Hal: Who else has partial access?  Does anyone have full access? 
Fred, Hal, Joe: Discussion of overrides of privacy in emergencies.  Coupled with audit?  Yes.
Hal: Doesn't HIPPA require auditing of most access?
Fred: Don't know.
Michiharu (IBM): They are using XML … and are trying to add access control functions.
Fred: Their current access control is very weak in his opinion.  Information on access control is in the header.  There are ids for doctors, nurses, patients and fammily. In the body there are id references back to the ids.  These are tagged to elements.  These indicate what the access is.  This is amlost OK except the categories aren't all that clear. Not as clear as we'd like.  Also, the categories aren't uniform among hospitals.
Hal: E.g.  "Admitting Phycian" means different ghings at different instittion.
Fred: A disturbing example is the "VIP" tag.  A VIP's records are "more private" than others.  The problem is that this idea isn't nailed down in a way such that you can compute it.
Marlena asks for clarification on the problems with the categories and "computability".  Is the problem that assigning a given tag to a given person is a judegement call (like in the VIP case)?    Fred: Yes.
Fred: Another problem is that there access control on the header itself.  Header includes administrative info like phone number and address. And these are sensitive too.
Joe, Marlena, Fred, HAL; Discussion of VIP.   It isn't a role tag but rather a qualifer about patient.    Conclusion: Bad use of tag.  Different meanings in the same data structure.     Also, categories are too coarse e.g. "caregiver".
Hal: There are things we can fix and things we can't.
Fred:  We should be able to have requirements about granularity.
Hal: HL7 already allows access control down to an element level, right?
Fred: Yes.
Hal: XPATH?
Fred: Not yet.  We should go this way.  HL7 hasn't.
Michiharu: Any requirements for granularity down to the attribute level?
Fred/Hal: No.
Simon:  This is a valid point.
Fred disagress. The attributes rarely are structural.  Mostly about what kind of sub-record this is.
Fred: Primary process flow is creating a record; adding privacy content; care-giver signing it; storing it.
Hal: Does signing mean that the record is protected against modifications?
Fred: Legally, record has to be maintained unmodified for 20 years.  But you could add an addendum that changes how you interpret that record.  You need some way of changing it for lab results, change of privacy restrictions.   It is a version control issue.
Hal:  The org that created the data have the onus of this maintenance.
Fred: If you want to get your records on paper …
Hal: The requirement to maintain the record is on one party.
Fred: The requirement follows the record and its copies as the travel to an insurance company etc.
Hal: Is the insurance company required to keep the copy for 20 years.
Fred: No.
Hal: So a key issue is "who is the originator of the record".
Fred:  The true owner.
Hal: Is that the term they use.
Fred: No.
Pierangela: Do the privacy restrictions always go along with the data?
Fred: Yes.  They are part of the "chart".
Pierangela: You should be able to validate the restrictions once the chart leaves the home organization.
Fred: This is a hard problem.     Two organizations can't necessarily match up the access groupings correctly. 
Pierangela/Fred: Discussion of what can be evaluated e.g. "next of kin" etc.  There needs to be a unique way of identitify to whom the policy applies and who has access.
Pierangela/Hal: Issue of identifiers for the patient and the doctors.
Hal: Having identifiers that track back to the real people makes the problem easier.   We can say "Allow the access, audit it,  and if it is abused we'll call the cops".
Fred: In SAML, assertions go into the policy decision.  This isn't so for HL7.
Hal: What about changes to the restrictions.
Fred/Joe: Envelope changes around the original.
Hal: The machinery is the easy part.  The hard part is figuring out who can change the privacy restrictions.
Fred: Can you say for example, "No amendments allowed".  What if someone then amends the record.
Simon:  The doctor makes an alterations at every visit  How does this work in light of what you are saying.
Fred/Hal: It is an append operation.
Simon: What is the granularity of change?
Marlena: What gets "stamped" as an unmodifiable change?
Simon: Yes.
Fred: It has to do with the doctor signing the record, he believes.
Hal: Let's push on.
Fred: One way to maintina privacy is to encrypt data.  Yield the key only when you do want the other party to have access.
Michiharu:  XML encryption lets you encrypt each element with a different key.  This could be useful.
Fred: Agreed.
Hal: The question is "What does XACML specify?"  Is it  specific technology or a service?    He's raising this as a question.   We have to for example express the idea of individually protecting components.  How do we express this?
Pierangela:   What about administration of authorizations?  What are the issues?  Who authorizes the authorizations?
Fred: The patient can add/remove restrictions.
Marlena: There is the question of who gets to change the authorizations in general.  The meta-policy.
Fred:  Yes.
Marlena: This doesn't go with the record.
Fred: Yes there is extrisic info.

Fred: There aren't actually many privacy restrictions in practice.  Most patients just sign away the restrictions.
Hal: Chart contains all info or summaries.
Hal: What about my chart for a 2-week hospital stay.  Isn't "addendums" the more common case than record creation.
Fred: Probably.
Hal:  Just an observation …

Use Case Variant: Breaking the glass.
Fred: Info is held from the patient, or patient overrides restrictions via legal means.
Hal: If you can audit, you can impose sanctions after the fact.  The institution needs to follow due diligence, but can allow access given audit and sanctions.

Use Case #2  Digital Rights Management
Carlisle:  Two submissions:  David Parrot from Reuters and from Thomas …    Reuters doc was extensive.  Many were quite relevant.  Very worth looking at.
Tom: The space is complicated and convoluted.   Also, there are multiple bodies working on a language for rights expression. MPEG is leading because of sheer force.  The other body is W3C.  Also e-Books community.    Perhaps we should wait and see what the other groups produce?  Or should we go forward?
Fred: When is MPEG21 coming out?
Tom: 2003.  Lots of submissions from different companies.   Dave Parrot is scepticale that they will finish.  Maybe we should avoid DRM as a use case and avoid duplication with MPEG21.  Or we could go ahead.   
Hal: The Reuters doc focusses on enforcement rather than policy.  How different is DRM policy from other policies?    We should go forward on the use case until we see the similarities and differences between use-cases.  We need to be generalized enough to be suitable for many use cases.
Carlisle: What is the scope of our charter?  A policy for healthcare and DRM?
Hal: It is up to us.  We could decide just to protect XML docs <grin>.   Keeping or dropping a use-case defines the scope.
Discussion of scope.  How to deal with different use cases?  What about cases where a use-case is solved?
[BREAK]

Use Case ebXML:
Sekhar:  ebXML ver 1.0 . Registry clients can submit content to a registry.  Currently there aonly a defualt access control policy.  The default si "The content can be submitted given that it is submitted by someone the registry wants to accept."  There are no controls on reading the content.   Now (new version?), the client can specify who can read and who can modify and delete.    Anyone who submitted can modify or delete.  "Deprecate" is harder.  The idea is that no one else can create references to deprecated content.   
Existing users of the doc can continue.
The bottom line on this use case: Submitter can specify custom access controls. 

Hal:  With regard to linking to content – do you have to be an author to link to a content?  Can arbitrary links be done? 
Sekhar:  This is an issue I can take back.  As far as I know, anyone can link to a document that has been submitted to the registry.
Hal: The issue of the access semantics of linking is interesting: not difficult but unusual.
Bill: This issue comes up whenever there are multiple documents.
Hal: The deprecation issues makes things different.  
Sekhar: The idea is that once a doc is deprecated no one else can link to it.
Sekhar: A question on 2.3.4 "Order".  Did this come up in the last conf call?
Carlisle: Suresh brought it.  He thought there might need to be an ordering of rules for evaluation.
Simon: We have to specifiy an evaluation strategy for the policy.   "Ordering" is one tactic.
Sekhar:  An OR-of-AND semantic is a possibility.
Hal:  Order of what?  Simon raised up issues of resolving conflicting policies.  Ordering is one tactic.  But there is also the issue of conditions: a condition that must be fulfilled before a rule comes into play.   Also, what about the notion of actions that must be fulfilled prior to access.  This also requires sequencing.  What are the real world requirements?
Sekhar: I need to take back the issue of "conditions" to Suresh.

Financial Use Case
Hal: Can someone comment on this?
Carlisle:  This is from Simon.  The most interesting one is 2.4.2 Cross Marketing. Can I derive things from data.  E.g.  any contraints on use of data about family members with respect to marketing to you?
Hal: Can combine two or more sources of data and get info that doesn't have policy on the resultant info.
Marlena: There is the policy of barring sharing to begin with.
Hal: You can have data, but not cross-reference.
Pierangela:  If you agree to retrictions on data, and violate them you are subject to sanctions.  Clearly, you can't observe all violations.  You need non-technological means of enforcement.
Phil: An issue of transitivity.  Whe Alice gives info to Bob, Bob has sworn an affdavit and will get sued if there is a violation of access policy.  The tricky part is the transitive part.   Alice can require an agreement from Bob, but what if BoB passes it on to Mal.  Mal has to have agreed to the policy too.
Hal: We need to specify more than "yes/no" but also other actions the PEP takes.  Does the PEP make promises in advance and the PDP makes access based on the promised?  What about the PEP makes a request without full knowledge, and the PDP makes known the other conditions.
Phil:  If we are based on SAML, we can put in conditions but can't do enforcement.
Simon:  PDP can't enforce an advisory; can only enforce the policy as is written.
Hal: The PEP can enforce access. What else?  Maybe an audit.
Don: Four entities: A single company with two sub-divisions:  The bank division gets info on the user. The user says if the info can be given to the insurance subdivision.  Take Citibank: They want to enforce this policy.
Hal: People want to specify as a policy  restrictions that can't be enforced. E.g. you can watch this movie but not sell tickets for others to view it.
Pierangela: With respect to restrictions, you can have a legal requirement.  You can make the user agree to the restrictions or not get access.
Hal: On the list, there was discussion about what the PEP needs to enforce.  I'm making the distinction that enforcement may have to be beyond the PEP through technical means.
Bill:  There are possible technological enforcements – albeit outside XACML.
Simon: We can write info into the policy.  PDP can pass back advisories to the PEP.  You want to do this even if there isn't enforcement directly possible.
Hal: How to interpret the advisories.
Simon: An application issue about what advisory info the application understands.
Simon: Is the PDP supposed to provide advisory info to the PEP?  Yes or no.  I think yes.
Marlena to Phil: What was your point about transitivity? Certainly there are agreeemnts about distributing data that say that the distribution policy info must be carried with the data
Phil/Marlena/Pierangela/Hal/Simon: Discussion transitivity but really about lack of ability to enforce certain restrictions via technical means.
Simon: We can use advise for non-enforceable restrictions.
Bill: That works to the edge of your universe –as Pierangela pointed out.  Then it stops.
Hal: "Advice" can be ignored.
Marlena to Simon: Just because it can't be enforced doesn't mean that the restriction is "advice".

Phil: When you evaluate the policy, if there is something you don't understand in conditions, you have to reject it.  If you don't understand something in advice you can continue.   If you got a "no", Advice might have say a link to a policy center that might be able to give a yes. 
Phil: Conditions are of the form: you have to check, you have to agree. [Essentially: "musts"]
Pierangela: I don't understand the distinctions between conditions and advice.
Phil: If your processors doesn't understand a condition, it has to reject the entire assertion package.  If the processor doesn't understand something in Advice, the processor can still accept the assertion.   Advice consists of information that is peripheral to the main assertion.   E.g.  Assertion: Alice can access this file.  Advice: She can give it away to anyone she wants to.      E.g. Advice might consist of how to get a re-issue of an assertion.
Hal:  Advice as extra information that may only be interpretable by two parties that have a prior agreement.
Simon: Advice is an elementary thing like a rule book: No more specific information can be derived.
Marlena: I don't understand Simon's point about the non-divisibility of advice.
Hal:  The current output is "yes/no".  We'd have to extend SAML to include multiple conditions and advice.  What bucket does the advisory info belong in?
Simon: "Condition" is within the PDP.   If you can understand to advice you have to evaluate it.  It is something for the PEP.
Hal: We seem to agree on the decision, but the output can be several things. There are a set of things to be conveyed to the PEP.  Should these be sliced up into things that are enforceable and not?  How else?
Simon and Marlena debate whether or not the PDP knows what the PEP can enforce and therefore can put enforceable items in "conditions" and non-enforcable restrictions in "advice". Marlena thinks the PDP doesn't know the enforcement capabilities of the PEP. Simon thinks it does.
Hal and Simon discusses enforcement.  Discuss semantics of enforcement.  Simon says it is a matter of trust.  Hal says it is a matter of communication/understanding.  
Simon: Conditions should be computable.
Hal:  PEP should be as lightweight as possible; it shouldn't have to compute policy.
Hal: Private agreements are the enemy of interoperability.  We are struggling to avoid that.   If the PEP and PDP are in the same organziation, this is so much an issue.

Use cases from Hal 2.6
Hal: How do we provision policy to the PDP?  This is independent of policy expression.     Also, SAML has the notion of an authZ decision assertion.  There is a short list of possible inputs.  The PDP gives a yes/no and plays back the inputs.  If we had a policy lang, that could express the inputs, then that language could specify the access question and decision in a richer form than SAML currently does it.
Simon: Lang for policy involves a lot of machinery.  There is a practicality issue.
Hal: Example: If it is Tuesday and Subject is an admin then allow access.  Let's say we have a policy language that can express this.     This would be useful for SAML.
Hal asks Phill for clarification on SAML schema.
Phil: Specification of evidence is only OK for the authZ decision assertion type.
Hal: We only need to pay attention to this type of assertions.
Simon: I want to distinguish between the info in assertions and something else that the PDP wants to pass along as evidence. 
[General agreement about this.]
Hal: It is an open question about whether the evidence will include all inputs to the PDP for the decision or only the relevant ones.

Discussion of how the PDP gets further information about the user or other context information to use in the decision.   Conclusion: It depends on the implementation.