Draft meeting minutes July 24, 2013

Minutes for 24 July 2013 TC meeting.

Started at: 1:05 pm EDT

**Attendance:

Mike Davis (Voting Member)

Duane DeCouteau (Voting Members)

Mohammad Jafari (Chair)

Quorum reached ( 3 out of 5 (%60) of voting members)

1. Roll Call & Agenda Review.

2. Volunteer to take minutes.

Mohammad: I will take minutes myself.

3. Approval of minutes from previous meeting (July 3rd 2013):

https://www.oasis-open.org/apps/org/workgroup/xspa/email/archives/201307/msg00002.html

Unanimous consent.

4. Status update about the profile updates action items:

(a) XSPA-1, XSPA-2, and XSPA-3 are closed.

5. Issues about the profile updates:

(a) XACML 3.0 Subject Categories

https://www.oasis-open.org/apps/org/workgroup/xspa/email/archives/201307/msg00005.html

Mohammad: I also sent an email to the XACML TC asking for people’s comments on this. So far the suggested approach is that we differentiate between the access-subject (the end user) and the recipient-subject (the receiving organization).

Mike: I don’t have any problem with this as long as we keep backward compatibility and relate the new terms to the old ones, but is there anywhere in our use-cases that we need this feature? Why do we have to complicate things if we don’t really need this.

Mohammad: It makes sense to me to define the attributes more precisely. There might be potential value in it even if there is no immediate application.

Duane: There are use use-cases in which this makes sense, e.g. admin clerk sends a request on behalf of a doctor. The admin clerk will be the recipient-subject.

Mike: But in that case the sender does not even need to know the identity of the original user. The assumption is that there is trust between the two ACSs so the sender trusts that the receiver ACS will enforce the required policies on the end user’s access.

Mohammad: The DS4P masking needs the identity of the end user for the encryption.

Mike: It depends on the type of masking. If it is based on a user, it doesn’t need the identity of the end user.

Mohammad: These variations in the use-cases need to be clarified. I will extend the use-case section to explain these. We can leave this open for discussion in the review period of the XACML TC as well.

(b) Dynamic Consent Policy

https://www.oasis-open.org/apps/org/workgroup/xspa/email/archives/201307/msg00004.html

Duane: Extracting the consent directive and showing how this policy is going to be embedded in the request. We need to make it normative.

Mohammad: I will update the use-cases to reflect this as well.

Duane: I will add the example.

Mohammad: How does this relate to the consent attributes, apparently the “patient:” set of attributes also encode the consent directive.

Duane: Yes, but we need the more general dynamic policy mechanism to support more complex policies like DS4P.

Mohammad: Then we need to clarify that it is an either-or choice to avoid redundancy and inconsistency.

Duane: Agreed.

Mike: There are different purposes vocabularies out there and we don’t need to be prescriptive about the vocabulary.

Mohammad: This is not about the actual purpose vocabulary; it’s the attribute identifier. XACML privacy profile has already defined the attribute so my suggestion is that we harmonize.

Mike: I am in favor of harmonization as long as backward compatibility is guaranteed.

Duane: Changing this attribute requires changing all the existing implementations. So it will not be backward compatible.

Mohammad: I suggest we introduce both but make a note that we deprecate the old attribute and it will be phased out in the next versions of XSPA.

Unanimous consent.

(d) Definitions in the profile documents need to be edited/updated.

(e) Organization of the structure of the documents: use-case/ attributes/ examples

(f) Separate table for "consent" attributes.

(g) Give non-normative list of referenced values from HL7 vocabulary in the appendix.

(h) XACML Standard Rules: -the semantics of the attributes implies rules.

(i) Obligation Section in the XACML profile: DS4P examples/ Obligation parameters

(j) other issues?

Mohammad: These items are mostly editorial changes to the profile documents and I can talk to Duane about them offline.

6. Which committees are we going to send each of the profiles?

XACML profile: XACML TC

SAML profile: SAML TC

WS-Trust profile: XSPA TC

Mohammad: I suggest we send the HCS profile to the XACML TC as it is most relevant to them.

Unanimous consent.

6. Suggestion to hold the next call in 2 weeks as this is the peak of our tasks.

Unanimous consent.

Duane: Let’s set up a livemeeting for showing documents on the screen.

Mohammad: Will do.

7. Other business/comments.

None.

Adjourned at 1:55pm EDT.

Next call: Wednesday Aug 7^th at 1 PM EDT.

xspa message