[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AI#0087: Extending NameIdentifier schema
The specific use case in AI 87 refers to "making assertions about issuers", but I feel that it falls into the more general NameIdentifier changes that Scott is proposing. I'll start by saying that I don't (currently) have a need for this extension in my own product, but Scott and RLBob convinced me that there are clear enough use cases to suck me into the discussion. I must say that this is one of the places where I feel that a "loose bag of ANYs" approach to schema design would have made our lives much easier. If the formal definition of "identifier" is "a hunk of string or XML inside an <identifier> element", profiles are then free to specify encrypted things, new formats, or whatever they please. The core spec should still define a useful base identifier compatible with SAML 1.1, but the ANY would make everything else possible. So, to the specific use case: Currently our "Issuer" is a URI, while our NameIdentifier is a two part name/namespace pair. At first glance, we could easily define a specific namespace for Issuers, and then just put the URI in the name. Something like: <saml:Subject> <saml:NameIdentifier NameQualifier="urn:oasis:names:tc:SAML:2.0:issuer" Format="urn:oasis:names:tc:SAML:2.0:assertion#URI">http://saml.issuer.com</saml:NameIdentifier> </saml:Subject> - irving - > -----Original Message----- > From: Scott Cantor [mailto:cantor.2@osu.edu] > Sent: October 27, 2003 22:06 > To: 'SAML' > Subject: [security-services] NameIdentifier schema > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]