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] | [List Home]


Subject: Minutes of 20 May 2004 XACML Focus Group


Minutes from the 20 May 2004 XACML Focus Group

Present

Simon Godik
Michiharu Kudo
Anne Anderson
Ed Coyne
Frank Siebenlist

Very productive meeting!!!

Agenda:
1. New RBAC Profile
2. XACML Profile of SAML V2.0 Attributes
3. Hierarchical Resources proposal

Minutes:

1. New RBAC Profile
   http://lists.oasis-open.org/archives/xacml/200405/msg00070.html
     or
   http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/6806/wd-xacml-rbac-profile-02.1.pdf

   Since comments are still coming in from xacml-comment, so we
   decided not to discuss this yet.

2. XACML Profile of SAML V2.0 Attributes
   http://lists.oasis-open.org/archives/xacml/200405/msg00068.html

   Discusion of lines 94-96, which now say:
   
     "The value of the SAML Attribute's Name attribute SHALL be a
      URI reference that conforms to this format and that is
      sufficient to distinguish instances of this Attribute from
      instances of other SAML or XACML Attributes that have
      different semantics."

   Simon: why the term "URI reference" rather than just "URI"?

[ACTION ITEM] Anne to ask Eve why she used "URI reference".

[DONE]: Eve says "URI reference includes both URIs and URIs that
have a "#<internal name>" appended.  This term is defined in the
SAML glossary.

   Michiharu: In "conforms to this format", what is "this"?

   Anne: It is the format associated with the identifier
   "urn:oasis:names:tc:SAML:2.0:attname-format:uri".  That is, a
   URI.

   Michiharu: Why do we need a new "DataType" attribute as well as
   the "NameFormat" attribute?

   Anne: The "DataType" attribute is the data type of the
   <AttributeValue>.  The "NameFormat" attribute is the data type
   of the "Name".

   Simon: consider changing lines 94-96 to:

     "The value of the SAML Attribute's Name attribute SHALL be a
      URI that is sufficient to distinguish instances of this
      Attribute from instances of other SAML or XACML Attributes
      that have different semantics."

[ACTION ITEM] Anne to produce new draft with Simon's suggested
change, unless Eve's response indicates otherwise.

   Simon: should the Profile include something like "these
   attributes may be conveyed either in-band or out-of-band", in
   order to include SAML's Attribute meta-data proposal?

   Anne: looked at SAML's Attribute meta-data proposal, and it
   does not specify the XML attributes of an Attribute, but
   rather things like the location of the Attribute Authority
   that is responsible for issuing the Attribute.  Also, this
   Profile is carefully worded to say that this meta-data
   (i.e. DataType, Name, NameFormat) must be provided for each
   SAML Attribute, but does not specify how it is provided.

   Michiharu: should the Profile include how to map the SAML
   Attribute to an XACML Attribute?

   Anne: That is specified in a different Profile: XACML Profile
   for SAML:
   http://www.oasis-open.org/committees/download.php/5854/wd-xacml-saml-profile-02.pdf

   The "XACML Profile of SAML V2.0 Attributes" is to be advanced
   within the SSTC.  Its audience is producers of SAML Attribute
   Assertions who want their Attribute Assertions to be
   consumable by XACML.

   The "XACML Profile for SAML" is to be advanced within the
   XACML TC.  Its audience is producers of components of XACML
   systems (PDP Context Handlers, PEPs, Policy Issuers) that want
   to use SAML Queries, Responses, and Assertions.  This Profile
   specifies how to map SAML Attributes (produced according to
   the "XACML Profile of SAML V2.0 Attributes" to XACML
   Attributes.  It also tells how how to issue XACML Policy
   queries and responses and XACML Authorization Decision queries
   and responses using SAML wrappers to provider issuer, validity
   period, and digital signatures.

[ACTION ITEM]: Anne to update the "XACML Profile for SAML" to be
compatible with most "XACML Profile of SAML V2.0 Attributes" and
with SAML 2.0 syntax.

3. Hierarchical Resources proposal
   http://lists.oasis-open.org/archives/xacml/200405/msg00064.html

   There was general agreement that specifying a standard URI
   syntax for identifiers of hierarchical resource components is
   both do-able and useful.  These names should conform to IETF
   RFC2396: "Uniform Resource Identifiers (URI): Generic Syntax":

      <scheme> ":" <authority> "/" <pathname>

   where <pathname> is:

      <hierarchical component> [ "/" <hierarchical component> ]*

   The first <hierarchical component> should be the root of the
   hierarchy at the <authority>.  The syntax of each
   <hierarchical component> should be the representation of the
   component on the <authority> that hosts the resource.

   Since a single hierarchical resource may have multiple valid
   values for <pathname> (such as a UFS file whose path contains
   hard links), there must be a way to supply all valid
   <pathname> values so that policies that refer to a particular
   element in the hierarchy using one pathname will always be
   able to match.  Tentative conclusion is that multiple
   :resource-id AttributeValues should be supported for this
   (within a single <Resource>).  All such AttributeValues must
   refer to the same element in the <Resource>.

   Tim's URL match function proposal
   (http://lists.oasis-open.org/archives/xacml/200405/msg00075.html
   and following) can be used with the standard URI
   representation of hierarchical resource elements to do matches
   that take the hierarchical order of the elements into account.

   There was general agreement that Tim's URL match function
   should be extended to cover all URIs, and not just URLs.
   Since RFC2396 specifies that "/" is reserved as a separator
   between hierarchical components of the identifier, this means
   that matches can always be by component, regardless of the
   actual component syntax for various URI schemes.

[ACTION ITEM] Anne to produce new draft of the Hierarchical
Resources proposal that includes:
a. Standard URI syntax for hierarchical resources that are not
   XML documents.
b. New, expanded version of Tim's URL match function to include
   URIs in general.

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692



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