Shibboleth Developers

["Scott Cantor" <>]

> Aha.... so.... I thought you were trying to forbid values of 
> kind 
> "a@b@c"

I am. At least for the two attributes that exist today, those would be
illegal. It's an attribute-specific issue, not a general one. It's also just
a bad thing to do if you're going to use the @ as a separator for
serializing a two part structure, but it doesn't break anything now.

> OK, so what does the improvement mean - that "c" in 
> "a@b@c"
>  will be 
> treated as a scope domain, if the attribute is unscoped (that's what I 
> thought Shib was doing), or that it will be thrown away, if scope is 
> required, but not present in the XML?

If the attribute is unscoped, then the XML is 
<Value>a@b@c</Value>
 and you
can do whatever you want. No scope domain, by definition.

If the attribute is scoped than the XML is <Value 
Scope="c">a@b</Value>
 and
your extra @ is confusing, but it doesn't break anything. The scope is
distinct, and if there's no Scope provided, the value is considered illegal.

> Also, does the improvement affect the text representation of the 
> (un)scoped attributes in the HTTP headers? (our software relies on the 
> fact the scope is present after "@"; and if scope is absent, we use the 
> Origin domain name)

No, it doesn't affect the text. And there will never be a case in which the
scope is absent. Simply not permitted, by definition. Note that an origin
has in general multiple domain names, so a default just doesn't work. We
don't annoint one as "primary".

> ok, so the AAP has a "scope must be present" flag, or something to that 
> effect?

For now. Ian argued that it should be in a separate more global definition
file for the attribute and not in a policy file specific to an SP, and I
agree.

> BTW, you have many qualifiers (uri prepended to the attribute value, 
> scope domain,...), which, combined together, simply define the meaning 
> of the value; and could be replaced by one unique identifier.

Of course. We called it eduPersonEntitlement. You shouldn't apply filtering
to entitlements by parsing their internals. You can apply filtering to
these. Whether that's useful or not is for others to decide, but that's the
difference.

> :-) I simply assumed that the Target used "@domain" from the value, if 
> the scope XML attribute was not present. Of course, you may need to 
> restrict the scope of attributes presented by the IdP.

Sorry, I misunderstood. Way back in the past, we used to do that, but it was
a bad idea for all kinds of reasons, some related to SAML usage that I
didn't like. The NameQualifier used to be a domain and I used it as a
default, but we don't do that any more because NameQualifier is an interop
problem in SAML and it's used in specific new ways by some identifiers in
SAML2.

It also makes the attribute "dependent" on its enclosing assertion, which is
just bad for decomposition and understandability. I think the values need to
be self-contained, even if the meaning is derived from context.

-- Scott