Shibboleth Developers

["Oleksandr Otenko" <>]

Scott Cantor wrote:

> > well... on the contrary (or in addition to that?), I would prefer a 
> > consistent interpretation of "@whatever" of the attribute values. It 
> > appears that both scoped and unscoped attributes look the same after 
> > they've been accepted, but the meaning of "@whatever" is different. 
> > (Hence the mentioned problem with scope spoofing)
>
>
> Yes and no. The meaning of anything within an attribute value depends on the
> attribute. I think it's a red herring to claim that a string is somehow ever
> universal across attributes.
>
> urn means something quite specific in a URI, but something totally different
> if it's the name of an object (how about an atttribute for where my ashes
> are stored? ;-)
>
> Regardless, what unscoped attributes permit a suffix like that? None I know
> of. And it would be a bad idea to allow it, because it creates confusion, at
> least in a deployment that was using the scoped concept. If you don't like
> the concept, don't use it, and then you can interpret it however you prefer.

My confusion or feeling of inconsistency comes from the fact that the 
Origin (according to the documentation) checks if the value retrieved 
from DataConnector has "@whatever"; then, if that is present, it is used 
as the scope domain.

This logic defines the meaning that any Attributes used in Shibboleth 
have this special syntax, where "@whatever", if present, means a scope 
domain, which may be different to the default domain defined in the ARP 
(smartScope).

(and that is why I assumed that the Target uses the same approach).

(and that is why our software also makes the same assumption - if 
"@whatever" is present, its a scope domain)


Sassa

> Implementing "general" attribute support is the hardest part of this in some
> ways. Personally, I don't think we know enough about how things are going to
> be used to be making declarations about what's right or wrong. If we find
> out what's needed, we can build it. But in the meantime, it has to be kept
> as orthogonal to the rest of the system as possible so that it's fully
> replaceable.
>
> Strictly speaking, text-based export of the values is a hack. The real API
> is the encoded XML, because that's less ambiguous and contorted. Yet nobody
> wants to parse XML (good thing it's so "easy"), so we end up debating the
> merits of different hacks.
>
> -- Scott