Practical purpose of SAMLnScopedString

[Cantor, Scott]

> We noticed that one of our IdPs is resolving ePPN as an unscoped attribute,
> and we wanted to fix that. Then we realized: "hey, why isn't this already
> broken?" At least one of our IdPs that resolves ePPN as a scoped string still
> expresses the attribute in assertions as an xsd:string with no formal Scope
> element.

There's no Scope element in an assertion. There was a Scope attribute used in SAML 1.1 and that turned out to be a bad idea (non-Shibboleth code can't handle non-string attributes), so we abandoned it with the 2.0 changes.

> The delivered attribute-policy file on the Shib SP defines a ScopingRules that
> disallows "@" in the attribute value. The delivered attribute-map file invokes
> the ScopedAttributeDecoder. I can only assume that the
> ScopedAttributeDecoder is basically splitting all flat string values into scoped
> attributes prior to applying the policy.

Yes, that's what it does. Scoping is in the eye of the beholder. What is "scoped" is defined by what you tell the system is scoped.

> FWIW, nothing in the formal definition
> of ePPN appears to declare it formally as a SAML Scoped String either, it's
> just defined as a string that it is composed of a value and a scope separated
> by an "@".

The MACE SAML Attribute Profile explicitly defines how to express those attributes in both SAML versions.

> So if the scoped attributes are generally expressed as strings with implicit
> rules, and even the Shib IdP puts them (in at least some cases) on the wire
> without a specified scope, what's the practical purpose of defining the
> attribute as SAML2ScopedString vs just calling it a string?

I'm unsure of what context you're asking about. Do you mean the AttributeEncoder in the IdP? I think Nate answered that. It has significant impact on the internal representation and how the data is applied to things like filter policies. A scoped attribute value's "value" is just the LHS and a policy operating on its scope will work whereas a scope rule applied to an unscoped value won't.

If you're asking if you can produce an EPPN that works with a simple string encoder, yes, you can, for SAML 2 anyway, but it will behave differently in a variety of edge cases until it leaves the IdP.

-- Scott