Shibboleth Developers

["Alistair Young" <>]

>> the requirement for IdPs that talk to shibboleth SPs to use a
shibboleth URN
>>> There is no such requirement
it says in the document:
"...AttributeNamespace XML attribute in <saml:Attribute> elements
MUST be set to urn:mace:shibboleth:1.0:attributeNamespace:uri..."

sorry, I completely misread that - I thought it said MUST!

The proposal is for SAML profiles, not shibboleth ones when in fact the
proposed standard urn value is to stop shibboleth breaking.

You say it's not shibboleth but changing the urn would break shibboleth.

Why can't the URN be owner specific? e.g. for eDirectory attributes, why
wouldn't you use urn:novell:edir or something, rather than shibboleth?

The namespace uri is Shibboleth, there's no getting away from that. If a
non shibboleth implementation wants to transmit givenName, why would it
even consider using a shibboleth uri?

Why even impose uris on attributes? SAML provides the buckets, the
profiles provide the way you push the buckets about. What's in the buckets
has nothing to do with shibboleth or even SAML for that matter.

If you want interop, I'll believe decomposition and oids but it smacks of
too much control when you want to impose deprecated profile signatures on
actual attributes.

Alistair




-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

>> The thing that makes me uncomfortable is the requirement for a
>> Shibboleth URN for all attributes. givenName is nothing to do with
>> Shibboleth, so why should I have to use a shibboleth URN?
>
> If you're talking about the AttributeNamespace, there's nothing we can do
> about this. We long ago decided to insist on URI-based naming, and we had
> to
> pick a value to use as an indicator. AttributeNamespace is a required, but
> completely ill-defined attribute. It creates problems and the best of a
> bad
> set of options was "pick one value and stick with it".
>
> It happens to be a urn:mace:shibboleth URN. That doesn't matter. It
> doesn't
> mean "shibboleth", it means the AttributeName is a URI.
>
> Changing this now is simply not an option for us because the eduPerson
> attributes have already been bound to these names and this software is in
> use. What would you propose we do?
>
>> So, whereas we've got rid of one hard coding scenario for SPs,
>> eduPersonTargetedID, we've introduced another - the requirement for
>> IdPs that talk to shibboleth SPs to use a shibboleth URN. Guanxi
>> IdP/SPs use whatever URN you want and I think this is the way
>> it should be.
>
> There is no such requirement. The requirement is that we've already bound
> a
> large set of attributes to this syntax. Changing this for no good reason
> is
> not an option that I can see pursuing.
>
>> Shibboleth (the implementation) is a filter that matches rules against
>> incoming attributes. You can specify whatever URN you like for an
>> attribute. Now it seems that is not allowed and you must use the
>> shibboleth URN.
>
> Huh? You've lost me. There is no such requirement being imposed. This is
> *not* a Shibboleth profile in any way. It is a SAML profile of the
> eduPerson
> and related attributes.
>
>> I welcome the decomposition and OID but I'd like some reassurance on
>> the URN that perhaps I'm reading this wrong way.
>
> Completely.
>
> -- Scott
>
>