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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: Draft SSTC F2F minutes for afternoon of Friday, 5 February 2004

SSTC F2F meeting
Afternoon of Friday, 5 February 2004

Action Item Summary
ACTION: Eve: Make a proposal that meets the W-28a* goals and
discussion points.

ACTION: John H. to take on editorship of the new "baseline
attributes" specification and gather text from Prateek, RLBob,
and interested others.

ACTION: Eve: Add an issue to the issues list about adding prose
to warn against using xsi:type on <AttributeValue>.

ACTION: Eve Add an issue to the issues list about Ron's
"description of SubjectConfirmation/KeyInfo in
SAML core precludes impersonation" issue.

ACTION: Eve: Put out a call for a new editor for the
Implementation Guidelines document.  (Ask the Liberty folks too.)

W-28a*: Attribute Usage
Goal: accept solution proposal

Latest document (from Feb 4) is at:

Section 4 has the proposed modifications.  A recent XACML telecon
generated a lot of discussion on this document and on the
differences between SAML and XACML attribute usage.

Reviewing the proposals:

4.1: AttributeNamespace: Change this attribute explicitly to a
URI that indicates how to interpret the attributes.  Could cover
a lot of common schemes.

4.2: AttributeDesignatorType and AttributeDesignator: No changes
needed, but some text has to come out because later proposals
have AttributeType no longer being derived from
AttributeDesignatorType.  This goes with 4.3:

Scott: Not sure we need to go to such lengths in the schema; we
can just throw some optional attributes on existing types.

Rebekah: A good example is LDAP attributes, which don't carry
datatypes, whereas XACML-style attributes do.  Attempting to
provide ability for someone to use AttributeNamespace and
Attribute and have that be enough.

Scott: But optional XML attributes on SAML elements could be
enough; if values are present, great.  There's no (XSD) schematic
connection between the XML representation and the LDAP- (or
whatever-)type attribute.  So you have to make this connection in
prose anyway.  Thus, keeping the schema simple makes sense.

Rebekah: Would the XML attribute holding the datatype go on
AttributeDesignatorType, then?

Scott: Either that or AttributeType.  [Note: Proposal 4.3
suggests that it would need to be on the designator, not just the
value-holding response.]

Scott: the attribute currently doesn't tell the consumer what
type its value is.

Hal: XACML has an evaluation engine with type-checking, and it
doesn't want to build in knowledge of specific attributes.  It
should handle arbitrary ones.

RLBob: So you need schema definitions that plug in to the engine.

Scott: XACML uses built-in types plus XPath in order to achieve
the goal Hal mentioned.  All attributes have become self-

RLBob: Does the XACML model require that attributes be annotated
with type information?  (All: Not sure.)

Eve: The current proposals set up two types/elements, one with
required type information and one without.  Instead we could have
one element with an optional datatype field.

Scott: If we're comfortable with not providing a guarantee about
being able to map to XACML attributes without additional run-time
logic, that mapping could deal with both situations.

4.4: AttributeType and Attribute: Here, an <Attribute> element is
proposed to contain <AttributeDesignator> rather than derive from

Eve: It seems a bit weird to put the typing information on an
older sibling of the value, compared to the value itself or the
value's parent.

Scott: The important thing is that this is type information on
the attribute (regardless of choice of XML expression) that can
be used to validate that all values for the attribute are the
same.  Currently, SAML allows a different value for each type.

Eve: So the goals are to specify the type-as-a-URI for both
attribute designators alone and for whole attributes and
enforcing (when desired) that all the values in an attribute have
the same type?

All: Questions about the complexity of requiring that a returned
attribute has the specified type.  There are many weak-matching

ACTION: Eve: Propose a set of options for achieving the above
(and below!) goals.

Scott: The overarching SAML<->XACML goal here is to be able to
profile the SAML attribute functionality in such a way as to make
it compatible with what XACML expects.  Is that right?  SAML can
make new optional functionality available, but to use it
successfully with XACML, it would have to be "profiled" to make
some of the optional parts required for that purpose.  If XACML
can then explicitly acknowledge the lack of suitability for some
kinds of SAML statement that were created without regard for
XACML needs.

Rob: But I thought the goal was (stronger) alignment, not
(weaker) profiling.

Scott: Pure alignment would mean always requiring the type
information on attributes, though not necessarily on queries.

RLBob: But if you want to query for all attributes of a certain
type, you'd need to supply type information in the query.

Eve: Note that we have a work item W-12, currently in Reassess
mode, about querying attributes by type.  So we're not taking on
this second use case.

Eve: We can finesse this by defining a type URI that means "the
type is application-specific" and making it the default.  Then,
the SAML syntax will be fully aligned, while not imposing extra
burdens on SAML users who are not interested in XACML

RLBob: Are there uses for the type information beyond XACML?

Rob: Can this be spec'd to allow for such uses?

Scott: No.  The process of defining profiles of attributes should
include defining whatever other details are needed to work with

4.6: ScopedAttributeValueType: This proposes a new field for
holding scoping information (e.g., department name) that people
are currently (ab)using AttributeNamespace for.  It's proposed to
go on a special version of the value element as a required field.

RLBob: Scope, for Shibboleth, means -- for example -- that a
faculty member's name is in the value and the department is the

Scott: There are many different meanings of "scope"!  If we
separate out what AttributeNamespace is being used for sometimes
now, let's consider that the attribute name's format.  Then we
can work on all the other things that might be called "scope".
This nets out to accepting proposal 4.1 but changing the XML
attribute's name to NameFormat.

Eve: +1

Irving: This feels like piling mechanisms on top of mechanisms.

Rob: In my heterogeneous environments, I might need to set up
lots of different formats.

Irving: But everyone will have to support all the possible
attribute name formats.

Eve: No, this will be a piece of configuration data just like all
the others that we have for name identifiers etc.  And it
codifies, in a more useful way than SAML V1.x did, attribute

Scott: So AttributeNamespace could disappear and be replaced by
one or more fields that are more precise about the purpose they

Scott: In Shibboleth, they have a ScopedAffiliation structure so
that you can provide important information along with your
attribute value (faculty...of what? the law school?) in order to
give context.  This seems to be a common enough need that SAML
should have it.

Eve: To preserve clean separation between SAML's semantics and
application-specific attribute value semantics, SAML shouldn't
have this; it should be up to people putting their own stuff
inside/on <AttributeValue>.  Should we improve our schema
extensibility features for this element?

Scott: We probably can't do better than xs:anyType, though maybe
we need some prose with a "health warning" that warns against
using xsi:type, which requires that the extension schema be

ACTION: Eve: Add an issue to the issues list about adding prose
as described above.

Eve: What about a field for the "source" of the attribute, in the
sense that Rob and Prateek have reported using AttributeNamespace
in the past?

All: Seem to generally like this idea.

John H.: This seems to work for DCE.

John H.: What if you want to supply a "friendly name" along with
the GUID, the way DCE does?

Eve: Maybe we should put <xs:anyAttribute> on AttributeType.
This would allow you to slap any global attribute onto
<Attribute> without needing a schema for them.

Several: Yes.

W-21: Baseline Attribute Namespaces, Bob Morgan
Goals: accept solution proposal; decide issue of actual baseline


Do we need a separate document that specifies Selected Attribute
Type Usage?  It would be normative to the extent that, if you use
particular URIs, you must use them in the prescribed way.  This
is similar in spirit to the Implementation Guidelines document,
but should be separate.  These would be our baseline attributes!

ACTION: John H. to take on editorship of this new document and
gather text from Prateek, RLBob, and interested others.

New issue: Description of SubjectConfirmation/KeyInfo in
SAML core precludes impersonation
Ron sent mail to the list about this today:


SubjectConfirmation has a KeyInfo field that's defined to say
that it's the cryptographic key held by the subject.  If we relax
the restriction to force the subject to hold the key, we can
handle impersonation.

Proposal: The text in SAML core should be changed to say
something like this:

[line 676] An XML Signature [XMLSig] element that identifies a
cryptographic key that must be demonstrated to satisfy the
confirmation method.

Hal: The original wording allows additional entities to have a
copy of the key, in addition to the subject.

RLBob: We would have to say "see discussion of impersonation for
more information".

ACTION: Eve: Add this issue to the issues list.

W-27: Security Analysis Enhancements
Goal: report status

Scott: The primary recommendation of the IBM paper is to
mandate SSL.  But we're not willing to do that, though we
strongly recommend it.

Prateek: This is something that the paper author may not have
realized, despite our best efforts in the Bindings document.

We will carry this forward; we're doing some profile work that
may impact this.

W-30: Migration Paths
Goal: report status

The group began discussing the issue of how/whether to allow a
mixing of versions of assertions vs. protocol messages.

We're disinclined to allow this.

Any Other Business
Eve gave a report from the editorial team.  "Revision-less" forms
of the documents and specs will soon be available, meaning that
people will be able to bookmark permanent URLs for them.  For
specification documents other than schemas, there will still also
be "revision-ful" forms available.

ACTION: Eve: Put out a call for a new editor for the
Implementation Guidelines document.  (Ask the Liberty folks too.)

The group voted to thank Hal Lockhart and BEA for their wonderful
service in hosting the meeting this week.  A round of applause

Adjourned at 3pm ET.

Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com

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