OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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

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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]