relevant SAML F2F items from the minutes

[Frank Siebenlist <franks@mcs.anl.gov>]

I just wanted to make the WGs aware of the two items that were discussed at the 
recent SAML F2F and that seemed relevant to XACML and the ogsa-authz's 
authorization decision query requirements.

FYI.

Regards, Frank.

----------------------------------------------------------------------------------
    W-28b: Deprecating AuthorizationDecisionQuery and 
AuthorizationDecisionStatement, Prateek Mishra
    Goals: Make a decision!
    Document: TAS

Prateek: Told XACML to not wait for SAML before proceding
Prateek: Asked who is using it - Rebekah said NASA is - and XACML closed issue 
list for XACML 2.0
Hal: not sure that's true
Prateek: so won't drop these in SAML
Scott: can we import from 1.1 schema?
Hal: XACML will do XACML specific one, would prefer not to see additional 
features added.
Steve: they do not want to add too muc to their scope
Bob: no one here is going to write the text to complete the item
John: is the perception that it is broke?
Rob: just not powerfull enough
Hal: at the time it came XACML was not very mature and needed something simple
Scott: freezing will mean some work - copy into the schema - not the amount of 
work - conceptually bringing it in requires work
Rob: still need to do that if deprecating rather than removing
Scott: can we reuse existing schema rather than pull it into ours in 2.0?
Eve: to implement entire XACML to do simple auth may be too much
Hal: any PEP can only provide info that it has
Hal: deprecation could be non-specific about which version will not have it
Hal: this additional functionality could be CD in XACML before SAML 2.0

MOTION: Steve moved to freeze this functionality as is for SAML 2.0,
no further functional enhancements, with suggestion that anyone needing more 
functionality look at XACML,
Hal seconds

Discussion

Rebekah: isf it is not deprecated I am comfortable with the motion as is
No objections, passed.

----------------------------------------------------------------------------------

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

Latest document (from Feb 4) is at: 
http://www.oasis-open.org/apps/org/workgroup/security/download.php/5312/draft-sstc-attribute-03.pdf

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: TypedAttributeDesignatorType.

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- describing.

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 it.

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 scenarios.

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 compatibility.

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 XACML.

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 scope.

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 names.

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

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 
available.

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.

----------------------------------------------------------------------------------





-- 
Frank Siebenlist               franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory