[xacml] pm call on jan28-02

[Simon Godik <sgodik@crosslogix.com>]

Title: pm call on jan28-02

Raw minutes.
1. saml encapsulation of xacml policies.
hal: are we at risk of changes made to saml?
gil: are we extending basic assertion
hal: we will define policy statement.
gil: you also minimize risk of saml changing
ann: handling of authentication and integrity check are to the prp.
saml is one possibility, another is x509 attribute certificate.
hal: we never clarified the role of prp.
carlisle: prp finds policy for the request. does pdp trust implicitely and
absolutely to prp? Who will check the signature on the policy: pdp or prp?
ann: information in the assertion hdr may not be passed to the pdp. This
info should be communicated by some other channel.
carlisle: i agree.
hal: you still need validity date.
ann: i think prp can check the validity date.
ann: i think prp and pdp will be closely coupled but functions are separate.
hal: xacml is an interchange format. At some point we have to deal with version
information, who is the issuer, so on.
gil: how much intelegence you whant to put into prp?
hal: i would like to avoid this issue by saying that the person who writes a
policy should provide this information (issuer, validity, etc.)
ann: xacml is a policy language and exchange format can be a layer that
encapsulates this format. a protocol by which xacml statements are transmitted
from one entity to another.
hal: assertions are free-standing and it's a good idea for xacml.
gil: if we accept that xacml assertions are free-standing than they should
be encapsulated somehow. is that right?
carlsile: i'm happier with the idea that assertions are free standing and
they need header information. does it make to look at saml and reuse what
they have there? or use x509 certificate?
ann: x509 syntax may be different, but semantics are identical. in addition
they have better developed infrastructure. xacml policy statement could be
embedded into x509 attr cert.
gil: this sounds like binding-profile discussion.
jason: x509 processing is not easy.
hal: we can leave x509 layer unspecified, but we can not leave xml wrapper
unspecified.
carlisle: i'm in agreement: we can talk about other types of encapsulation,
we should start with xml encapsulation. i would lean toward saml encapsulation.
carlisle: do we see a need for conditions and advice?
hal: yes. saml does not define anything specific about those buckets.
carlisle: do we need to define policy statement?
hal: we can sublass saml:statement.
ann: sounds good to me.
carlisle: is this thing always signed or not?
hal: i would suggest adopting their dsig profile. if you wrap it in x509 why sign the inner piece?
carlisle: sounds we have an agreement. this is our tentative resoulution.

2. arithmetic and interval operators in xacml expressions.

carlisle: at least some sort of difference operator would be usefull.
there might be other operators as well. Do we want to add operators for
version 1.0 and which ones?
carlisle: how we can find out what's available?
ann: we need to include string matching comparison algorithms.
carlisle: sakhar agreed to explore schema.
gil: ldap attribute syntax definitons are defined in rfc 2252
carlisle: should there be general extension mechanism?
ann: another way to deal with arithmetic is to use transform attribute.
ann: specific examples are needed for comparisons.
carlisle: we want extensibility in operators, amd we want some operators to be
called out.
simon: please provide examples.
carlisle: tim will provide 0.9 schema by friday. (endofday)

3. Applicability.
Ann: if a target (resource+subject) matches request, but resource or subject
expression evaluates to false, what should we return: deny or not-applicable?
Issue: this is subject to discussion on the list.

Carlisle: 0.9 out by the end of day friday. We'll talk again next monday.