OGSA-Authz-WG Telecon Dec 4th 11am CT

Note by Von Welch. Clarifications from Rebekah Lepro in brackets.

Attending:
Andrew McNabb
Rebekah Lepro
Von Welch
Markus Lorch
Mary Thompson
Frank Siebenlist

VW: Like new text in sections 3 and 5.2.1

RL: section 3 - like general content. Advantages are only done for
subject attributes, privileges attribute text is only descriptive -
should be consistent. Make comparison in separate paragraph.

VW: (sec 3)Subject attributes and resource attributes need to be clarified as
to their being subtypes of descriptive attributes

RL: (sec 3) Is positive vs negitive a discussion or requirement?

[RL:  Are positive vs. negative attribute statements addressed as general discussion or as a requirement?]
 
VW: I think this is a recommendation, just needs to be made more
clear.

ML: Maybe we can convey implications of having negitive rights?

VW: Section 3 could have subsection to make more clear.

MT: Does 4.3 make sense? I wrote it now not sure it makes sense.

RL: Yes it does, will double check with finer-tooth comb

MT: Mainly it was "where is the value of attribute"?

RL will look at 4.2 and 4.3 to ensure attribute definitions are true
to standards and clear to reader.

RL: Section 5.2 is sentance on case sensitive comparison correct?

MT: Add text to say case-sensitive comparison is default unless
overridden by underlying mechanism.

[Should this say for attribute names/identities/values or is this the default just for value comparisons?]

VW: Moving on to 5.2.1

RL: Subject has union of all groups of which it is a member. Seems
like this is part of policy.

[like this statement tries to specify how to interpret multiple groups which should be part of policy or ADF]

VW: VO membership is type of group

AM: That is what we do.

RL: Back to group union comment...

VW: Maybe we just say that person can be member of multiple groups and
what that means is out of scope.

ML: Do we say that VO membership is just a type of group membership so
it should not be an attribute type, but we just say that vo membership
should be expressed as a group membership?

Group agreed.

AM, ML raised issue of how hierarchical groups should be named. This
was tabled by Von until we finished going through document.

RL: Citizen attribute - what about the ldap citizen attribute? was
called on in the xacml section (last sentence in 4.3) This exists in
multiple places and last sentence of 5.2.1 states we should be using
xacml.

VW: Last paragraph should be moved up to begining of 5.2.1 or 5.2

VW: Suggest making privilege attributes separate to reflect 3

MT: But "privilege" is just an attribute name

ML: How about making descriptive attributes and privilege attributes
section?

Agreement reached.

VW: Value for privilege attributes is complex while descriptive
attributes is opaque string.

MT: Privilege attributes with different names?

ML: I did that in early work, wasn't hard but didn't see any
advantage.

MT: Maybe want to have talk about different names for privileges?

VW: I'd say unless we have strong use case for this, let's not.

MT: How about some text just saying we decided not to do this and why.

VW: Sounds fine.

RL: Back to naming discussion... In the XACML stanadard (line 4539),
where a suitable attribute is defines in LDAP, that name shall be used
for basis of XACML name (programatic method given in XACML)

RL: Since we are deciding to follow XACML for other things, maybe we
should be consistent in doing so.

MT: OK, will follow XACML for citizenship attribute.

MT: Does XACML have a list of attributes?

RL: Yes, it's in an appendix which we can reference at start of 5.2.1

VW: Point of order: We're over a hour - Next call in two weeks on the
18th? Will try to have conversation re SAML Authorization.

Agreement.

Call adjourned.