Shibboleth Developers

[Alistair Young <>]

The decomposition of eduPersonTargetedID into xml elements is an 
interesting move. I can see it sorting problems, especially of hard 
coding syntax, also the OID use for new attributes is good for interop, 
though a bit more effort on the developer side.

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?

Shibboleth is a SAML profile, so what you seem to be doing is 
profile-qualifying attributes. I can't see any other reason as 
shibboleth don't "own" the attribute and shibboleth isn't a URN 
provider in any way, so it seems to be a profile qualifier. The 
attribute now seems to be bound to the implementation of whatever 
profile you're using.

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.

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.

Are we just seeing another strand in the shibboleth web? i.e.
Shibboleth - the protocol
Shibboleth - the implementation
Shibboleth - the default implementation of attribute URN

I welcome the decomposition and OID but I'd like some reassurance on 
the URN that perhaps I'm reading this wrong way.

thanks,

Alistair


On 18 Apr 2005, at 07:55, Scott Cantor wrote:

> Attached is a first draft of a pair of SAML attribute profiles for 
> mapping
> eduPerson and related bits to SAML 1.x and SAML 2.0.
>
> The 1.x profile is mostly documenting current practice on the wire, 
> bad or
> unpopular decisions notwithstanding.
>
> The 2.0 profile is a stab at "the way we want it to be" and should be
> carefully vetted well before we put anything on the wire and end up
> committed to it.
>
> eduPersonTargetedID is a problem for both profiles, and my proposal 
> needs
> debate, particularly whether to start supporting a "new" syntax in the 
> 1.x
> profile or just leave it imperfect and wait for 2.0. This depends to 
> some
> extent on expected volume of use. But we need to decide quickly if a 
> new
> syntax is to be supported in Shibboleth 1.3.
>
> This proposal formalizes all the stuff on the wire that isn't in the
> Shibboleth spec at this point, so it's a key piece of the puzzle to get
> published.
>
> -- Scott
> <draft-internet2-mace-dir-eduPerson-SAML-01.pdf>