Practical purpose of SAMLnScopedString

[Eric Goodman]

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

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.

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

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.

>A scoped attribute value's "value" is just the LHS 

>From the MACE Profile snippet, I thought maybe it was implying this was a requirement on the wire too. E.g., that the scoped attribute's "value" must be expressed separately from the scope. Understanding that the internal encoding type is distinct from how the value is expressed in the assertion clarifies things. 

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.  

My concern was that if the "scope" actually needed to be expressed separately from the attribute's "value", then sending ePPN as a flat string could impact the SP's ability to apply scope rules to it. Clearly that's not the case, but the language combined with the MACE example, got me wondering why not. 

Thanks,

--- Eric