Subject: RE: [security-services] Conformance with identifiers/affiliations (long)
I would support addition of transient and one-time NameID format and affiliations into all of the SP and IdP conformance modes. My reading of the ID-FF 1.2 SCR is that these were considered separately purely for historical reasons (developed later in the game). One question is whether we need to add more text to conformance enumerating these features, or whether it is enough just to strike the two columns from the extended IdP/SP matrix. NameID Mapping and IdP proxying feel like somewhat more heavy weight features. My suggestion would be to maintain an extended IdP/SP operational mode that incorporates these features. - prateek -----Original Message----- From: Scott Cantor [mailto:email@example.com] Sent: Tuesday, August 03, 2004 5:08 PM To: SAML Subject: [security-services] Conformance with identifiers/affiliations (long) Right now, we have SP-Lite, SP, SP Extended, IdP-Lite, IdP, and IdP Extended conformance modes for the SSO material. The Extended modes add MTI requirements for the these four capabilities: - the transient NameID format - affiliations - NameID Mapping Profile over SOAP - IdP Proxying I think the first two need to be captured some other way, if at all, and I'm not sure NameID Mapping is an SP thing anyway. It's more of a building block piece for additional profiles. Needs some discussion next week maybe. Regarding the various formats, it's probably worth discussion about what it means to "support" them, in the vein of the NameID mgmt thread. In general, it's reasonable to require any SAML toolkit to be agnostic about this stuff. Just tell it what the right values are and you're done. I think everybody has that part. As far as an IdP, any of the normal, persistent formats that were around in 1.1 essentially require that the IdP is storing data or communicating with a back-end of some sort but there's nothing it has to explicitly do at runtime to "support" them. Transient (One-Time) Format With the "transient" format, you have essentially a requirement that you can create an opaque value on the fly and maintain a temporary association between it and a real underlying value. This is generally easy to "enable/support" (as opposed to directly implement), and is also possible to do in a stateless fashion with encryption as well, so even that's not a problem. Therefore I don't see a good reason not to make it MTI for all IdP types. Obviously, I'm biased on this. On the SP side, I think it's less obvious what it means to support anything explicitly, because we aren't dictating anywhere what it really means to consume SSO assertions, apart from adherence to subsequent profiles such as Logout. I believe that in effect, an SP from a conformance standpoint is playing string matching games. "If you get this value in this message and then this value in that message, then do X." At that level, all of the formats are the same, and transient may as well be emailAddress. The most you could say (and I guess this is maybe what some are thinking) is that as a product, you may add various features that only make sense when the identifier you get is more persistent. I think the more direct argument is that transient identifiers don't stand alone, but have to be combined with other profiles and/or data to be useful. Liberty deployers might choose to use ID-WSF in conjunction with them, the Shibboleth system chose to use SAML attributes, etc. So, I suppose I'm prepared to acknowledge that maybe it shouldn't be MTI for SPs, but I'm just not sure in practice how big a deal it would be if it was, if typical product features are combined in reasonable ways. I'm open to other thought on this. Persistent (One-Time) Format Moving on to the opaque, "persistent" format (formerly "federated"), there's not a lot to distinguish it from the others on a lot of levels. It's got to be stored somewhere, albeit with the additional name qualifiers and the ability to select the right value at runtime based on the SP/affiliation. Again, this could be internal or simply an interface to storage. However, this format is typically used in a more dynamic way than other persistent values. You *can* provision such values out of band, but it's more typical in Liberty to create them on the fly based on the equivalent to the AllowCreate flag in the NameIDPolicy. That implies write-back again. But, nothing *requires* that you implement it this way, unless you implement support for the AllowCreate approach. Therefore, I don't see a good reason not to make this MTI for even the IdP-Lite mode, with the proviso that by definition such a beast isn't creating them on the fly (otherwise it would just support NameID mgmt and be an IdP). On the SP side, I don't see anything about this format that is markedly different technically from an emailAddress and no reason for it not to be MTI. Affiliations Not that complex a topic. Any name identifier can be scoped to two separate name qualifiers. The persistent format calls this out as mandatory as a part of its value proposition. Affiliations are just a way to take multiple system entities and group them such that they share an SPNameQualifier value. At a technical level, this is simple...you have a mapping between SPs and associated affiliations so that you know how to go back and forth and interpret these relationships. With metadata, you have a formal way to express the mapping using an AffiliationDescriptor, but it ain't exactly rocket science. So, I guess I don't see a big issue with making this MTI. It's a naming trick to subvert (umm, supplement?) the privacy inherent in the protocols when using the privacy-preserving format. If you support the format already, you're pretty much done. The delta here is tiny. -- 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.