Shibboleth Developers

["Scott Cantor" <>]

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

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