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