[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [security-services] NameIdentifier schema. Forwarded message from Scott Cantor.
Colleagues, I found this discussion interesting. Would there be any value to XACML changing from XML DataType attributes to XML tags? We would need to retain the DataType attribute in Designators and Selectors. I'm not recommending this, I'm just looking for discussion. Anne ------- start of forwarded message ------- From: Scott Cantor <firstname.lastname@example.org> To: "'SAML'" <email@example.com> Subject: [security-services] NameIdentifier schema Date: Mon, 27 Oct 2003 22:05:53 -0500 I took an AI to try and lay out some samples and possible alternatives for the NameIdentifier schema in 2.0. My latest draft document is here: http://www.oasis-open.org/apps/org/workgroup/security/download.php/4029/draf t-sstc-nameid-05.pdf Would like to discuss the following if possible during call, and bring this to closure. Nailing down a prelim. approach to this schema will get things moving, IMHO. Schematically speaking, I have two competing requirements: - degree of compatibility with 1.x - support for new attributes and non-string content I see two ways to add a new "kind" of NameIdentifier that can contain the EncryptedData/EncryptedKey elements. Either we can build a new type hierarchy that fits in the old NameIdentifier element slot of Subject, or we can add choice to the Subject element itself so the new type(s) can be used instead of the old type. My reasoning behind a new hierarchy of types is that both encrypted identifiers (and presumably other future complex identifiers) and string identifiers would need to share a common set of attributes, such as NameQualifiers and validity times. But this can be done using an attribute group as well, so there would still be schema reuse without type derivation. OTOH, I don't know if schema data binding packages recognize that kind of reuse, whereas I would assume type derivation is reflected as class derivation. My latest draft-05 reworks the names such that the current string-style identifiers remain called NameIdentifier / NameIdentifierType. I derived this from a new BaseNameIdentifier / BaseNameIdentifierType. My thinking here was to maintain some textual compatibility with 1.x, while acknowledging that the extra attributes I added would still be incompatible with 1.x anyway. But the real discussion probably needs to be around the Format attribute, and whether we want to proceed with this in-band non-XML approach to "typing" these elements. If you think about it, it's basically like what XACML is doing with their attribute typing, using an XML attribute to indicate a "type" via a URI so that the receiver knows how to process the data. I guess Irving might argue that it's a string identifier, and who cares beyond that, but I know at least in the federated vs. transient pseudonym case, I do care. The question is, should this be communicated with a URI attribute like Format, or by using different XML elements to signal it? For example, with other attributes omitted, we could do: <NameIdentifier Format="urn:....:federated"> foo </NameIdentifier> or we could do: <FederatedNameIdentifier> foo </FederatedNameIdentifier> In the former case, we have to have processing rules that dictate what the proper element/type is for that Format. And define what the various other attributes mean. And my proposal in fact includes those rules, including for the older formats from 1.x. In the latter case, do we still define usage of the Format attribute for these new elements, or do we leave that basically unspecified and assume that people will use the element or xsi:type directly? I would assume the latter. I did in fact originally have a proposal that resembles the second approach. What I think I failed to see was that using Format in that design was extra work, and required extra processing rules that aren't really useful. My reaction was to reduce the proposal to a Format-based design using a common XML element. It may be that my mistake was throwing out the wrong part. -- Scott To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php. ------- end of forwarded message ------- -- 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