[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: 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. W-21: Baseline Attribute Namespaces, Bob Morgan =============================================== Goals: accept solution proposal; decide issue of actual baseline attributes Documents: http://lists.oasis-open.org/archives/security-services/200401/msg00060.html http://www.oasis-open.org/apps/org/workgroup/security/download.php/4124/draft-morgan-saml-attr-x500-00.pdf 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: http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200402/msg00049.html 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 ensured. 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]