MHonArc v2.5.0b2 -->
xacml message
[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 <cantor.2@osu.edu>
To: "'SAML'" <security-services@lists.oasis-open.org>
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]