OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] Wed PM minutes


Title: Wed PM minutes

Minutes
XACML meeting
19-20th June 2002 afternoon

Present:
Anne Anderson
Tim Moses
Daniel Engovatov
Bill Parducci
Simon Godik
Michiharu Kudoh

1. Context

Version 14 contains a schema for Context with two top-level elements: request and response. 

Discussion of the <subject> element and whether it is permissible for it to be empty.  Decided to allow it to be empty.  Daniel wants to be sure that we can write policies that explicitly deny access if the subject is unknown.  Michiharu points out that an XPath expression for a missing element is the empty set and this translates to false, if the result is converted to boolean.

The subjectId should allow for ds:keyInfo to address the case where the subject has proved knowledge of a key, but not supplied a name.  Simon asks how we could write a policy that depends upon the method used to authenticate the subject.  SubjectId should be a choice of xacml:NameIdentifier or ds:keyInfo.

Discussion of <holder>.  Decided to take <holder> out of the context.  The AttributeDesignator in a policy is simply an XPath expression of type xs:anyURI.

Discussion of importing saml schema definitions (DecisionType and AttributeValue).  The meeting preferred to eliminate any definitions imported from saml.

Decided we need an <xacml AuthenticationInfo> (method and instant) element descendant to Subject.

Resource: there is one and only one in a context instance.

Decided to remove the xacmlContext:ResourceContentType definition, and redefine the type of <xacml:ResourceContent> to be xa:any.  Then the XPath expression in the policy <Attribute> proceeds down into the resource, if it is an XML document.

In Section 7, we need to define an identifier for ResourceDigest.  The Resource <Attribute> will have the same type definition as the Subject <Attribute>.

Decided to use name SubjectCategory instead of SubjectFunction.

The meeting discussed the fact that the <ResourceContent> can be greater than the resource identified by the ResourceURI.  i.e. conditions may reference parts of the resource other than those to which access is being requested.

Michiharu wants to allow a PDP to return multiple decisions in a single response for each separate descendant element and attribute of the resource defined in context.  Can this be indicated in the request using the facilities of XPath? 

Simon will modify the schema for "function", and table it for discussion tomorrow morning.  And he will provide examples.

We may not resolve Michiharu's issue during this face-to-face.  But, resolution may have to await discussion on the list.


-----------------------------------------
Tim Moses
Tel: 613.270.3183



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC