Practical purpose of SAMLnScopedString

[Cantor, Scott]

> By "element", was referring specifically to the encoding shown on line 305 of
> that profile:
> 
>    <saml:AttributeValue Scope="osu.edu">cantor.2</saml:AttributeValue>
> 
> Which doesn't seem to actually be used.

Attribute would be more precise, but yes, it's definitely used (in SAML 1.1 by default).

> We were wondering changing the encoding from String to ScopedString
> would cause any issues for SPs. Clearly no, modulo internal edge cases that
> are completely internal to the IdP, but that was the genesis.

For SAML 2, the on the wire rep is the same. That is not true with SAML 1 (but that's a different encoder which defaults the scope representation to the non-inline option).

> I will note that the statement about the value being "just the LHS" is (which is
> made multiple places) is partially confusing because the distinction doesn't
> exist practically in the SAML assertions nor in the applications receiving the
> assertions, virtually all of which include/store/consider the scope as part of
> the attribute value.

That's not the case in Shibboleth until the headers get produced (wherein it recreates the flat string with the @ sign). If you tell it that something is scoped by applying the ScopedDecoder, then the value is solely the LHS and the scope is stored separately, and if you do things like transforms, that will impact things, or if you do attribute filter policies in the SP.

-- Scott