MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: SSTC Minutes related to SAML Attribute metadata discussion
These are the portions of the minutes from today's SSTC Focus
Group that pertain to the discussion of the XACML TC
recommendations for SAML Attribute metadata. There were no
decisions made, particularly no decisions about changing the
current draft in this area.
There was no consensus that even an optional "DataType" metadata
element is desirable for SAML. The prospect of conflicting SAML
Profiles or of large numbers of Profiles that must be used by a
particular application did not seem to impress them. They did
not seem to see any broad need for an ability to operate on
Attribute values other than by equality comparisons.
Someone proposed that XACML define a "profile" of SAML
Attributes, specifying, in our own namespace, the metadata
"required when SAML Attributes are used with XACML". It seems me
that applications are unlikely to structure their Attributes
around XACML, but that they would like to have their Attributes
interoperate with XACML without having to create special ones.
Hal has ownership of reaching agreement on at least some portion
of this. It was unclear to me whether discussion of separate
metadata only, or further discussion of the role of SAML profiles
vs. specifying generally useful metadata as options in the SAML
spec itself is covered under this "ownership".
[extract from minutes]
- Anne: emailed recommendation
< http://lists.oasis-open.org/archives/security-services/
200404/msg00019.html >
- couple of comments
- there was a question about pulling metadata into separate element,
and whether there would be an impact XACML -- it won't
- there was a question about having only one type for each attr --
won't affect XACML
- Want single, unique component to identify an attr
- Prateek: at F2F, was discussion around single attribute
designator
- Eve: sent email responding to Anne's latest requests
< http://lists.oasis-open.org/archives/security-services/
200404/msg00050.html >
- believes that this request is already satisfied
- Anne: not clear whether NameFormat is used to 'unique-ify' the name
- Eve: NameFormat indicates how to process the Name value, e.g. as
a URI
- Scott: there is no requirement to use the URI NameFormat
- there is no goal to unambiguously map attrs to XACML
- Anne: just wants to make mapping as easy and deterministic as
possible
- Scott: then would be very easy to write profile stating that URI-
based Names are required
- Anne: also trying to make it easy where an XACML profile isn't
followed
- Scott: in that case, there is no requirement in SAML for
uniqueness, so may not be feasible
- [...]
- Eve: SAML today provides adequate infrastructure to support this
- Anne: want datatype metadata to be required
- there are cases where values aren't available yet
- don't expect to get SSTC approval, so moving on to next point
- Anne: if metadata not required, at least define optional element
- more interoperable than leaving up to external profiles
- costs little to SAML spec, seems well-defined
- RLBob: conclusion at F2F was that people that are interested
in such use cases, they would follow an XACML profile where such
an attr would be defined
- Eve: recalls that it was removed was because it was confusing with
XSD means of typing
- however, XSD method seems little-used
- Scott: concerned more on the query side
- Eve: does have some language now to cover that
- Prateek: doesn't this fall into attribute profiling?
- Anne: but different attr profiles can define diff XML means of
expressing this
- Prateek: each profile can choose to omit the core-defined XML
- [...]
- Anne: concerned about conflicting definitions in different
profiles
- Eve: but these profiles will be defining namespace-qualified
constructs, e.g. "xacml:datatype", so there won't be a conflict
- Hal: doesn't think this should be characterized as an XACML
requirement, because people will sooner or later need this
datatype metadata
- Prateek: should we have a group go off and settle this?
- [...]
- Prateek: doesn't want to add this sort of thing without
doing it 'completely', a la an attribute profile or family
- Scott: proposed an approach at F2F that some felt was too
dynamic
- Eve: suggests adding this to the issues list, in category (b)
or (c)
- will put Hal as issue owner
- Rob: can put this on agenda for focus group
Anne
--
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]