SAML attribute naming

[Eric Goodman]

So I've always assumed that the SAML spec called out the use of URNs for attribute naming. Reading the SAML spec looking for that, it appears the spec actually defines a standard for using LDAP/X.500 attribute encoding - which does require use of URNs for attribute naming - but does not require the use of that spec for SAML in general.

I'm currently working with a vendor that is asking for attributes with names (not friendly names) such as "firstname", "lastname", etc.

Do I have any grounds to argue that those are invalid attribute names, and try to convince/force the vendor to provide urns for these? I will ask them to, but I'm looking for something that backs up a claim that using such names is "wrong" rather than just "not the way we do things".

(FWIW, the vendor also defines several vendor-specfiic attributes that also have non-URN values, and since those are specific to this vendor the non-URN-ness of those attributes may not be as much of an issue for us.)

Thanks,

--- Eric

[Peter Schober]

The page name even matches the subject from your post :)
https://wiki.shibboleth.net/confluence/display/SHIB2/AttributeNaming

Post by Eric Goodman
I'm currently working with a vendor that is asking for attributes
with names (not friendly names) such as "firstname", "lastname",
etc.

That's legal, provided the name format matches ("basic").

It's also less than helpful because "name" or even "givenName" could
mean anything unless it's accompanied with a reference to an existing
standard, e.g. an IETF RFC.
URI (not URN specifically) naming avoids that by using globally unique
names, which also reference the source of the definition uniquely.
So both parties can be sure of the syntax and semantics via reference
to an existing, external standard.
-peter

[Tom Poage]

Post by Peter Schober
The page name even matches the subject from your post :)
https://wiki.shibboleth.net/confluence/display/SHIB2/AttributeNaming

Post by Eric Goodman
I'm currently working with a vendor that is asking for attributes
with names (not friendly names) such as "firstname", "lastname",

...

Post by Peter Schober
URI (not URN specifically) naming avoids that by using globally unique
names, which also reference the source of the definition uniquely.
So both parties can be sure of the syntax and semantics via reference
to an existing, external standard.
-peter

Right. That didn't stop e.g. Salesforce from doing things their own way,
making more work for all of us, instead of leveraging standards or

Post by Peter Schober
<resolver:AttributeDefinition xsi:type="ad:Simple" id="User.Username" sourceAttributeID="eduPersonPrincipalName">
<resolver:AttributeDefinition xsi:type="ad:Simple" id="User.LastName" sourceAttributeID="sn">
<resolver:AttributeDefinition xsi:type="ad:Simple" id="User.FirstName" sourceAttributeID="givenName">
<resolver:AttributeDefinition xsi:type="ad:Simple" id="User.Email" sourceAttributeID="mail">

"No Software." It's replaced by configuration instead.

Tom.

[Eric Goodman]

Post by Tom Poage

Post by Peter Schober
The page name even matches the subject from your post :)
https://wiki.shibboleth.net/confluence/display/SHIB2/AttributeNaming

Post by Eric Goodman
I'm currently working with a vendor that is asking for attributes

?>> with names (not friendly names) such as "firstname", "lastname",
...

Post by Tom Poage

Post by Peter Schober
URI (not URN specifically) naming avoids that by using globally unique
names, which also reference the source of the definition uniquely.
So both parties can be sure of the syntax and semantics via reference
to an existing, external standard.
-peter

Right. That didn't stop e.g. Salesforce from doing things their own way,
making more work for all of us, instead of leveraging standards or

Both points are understood. It's easier for US if there are URNs. Hard sell to a vendor that (a) already has a contract and (b) says "'firstname' is clearly defined to mean the name value that matches the provisioned entry". For them there's no ambiguity and the value is "globally unique" in their world.

I know this isn't news, but I was going to argue that they weren't being SAML compliant, only to see that in fact they are. So now I need to get into more nuanced (and less likely to sway the result) arguments.

Thanks,

--- Eric

[Cantor, Scott]

Post by Eric Goodman
Both points are understood. It's easier for US if there are URNs. Hard
sell to a vendor that (a) already has a contract and (b) says
"'firstname' is clearly defined to mean the name value that matches the
provisioned entry". For them there's no ambiguity and the value is
"globally unique" in their world.

Of course, in every sector except higher ed, it seems like the "customer"
actually might have some say, so we seem to be really bad at fulfilling
that role. Maybe everybody is bad at it and customers have never had any
say.

Post by Eric Goodman
I know this isn't news, but I was going to argue that they weren't being
SAML compliant, only to see that in fact they are. So now I need to get
into more nuanced (and less likely to sway the result) arguments.

Yes, you can blame RSA for that primarily. I fought for URI naming
exclusively pretty hard and lost.

-- Scott

[Tom Poage]

... Hard
sell to a vendor that (a) already has a contract and (b) ...

In my experience, the game's all but lost at that point.

Tom.