common LDAP schemas to draw attribute definitions from

[Boyd, Todd M.]

While I don't disagree, the FriendlyName was not helpful when negotiating with haphazard vendors that require handmade metadata or strange configuration overrides in order to function. In a pure, ideal state of existence, the rigid, well-connected structure of the system and its documentation is enough. Pragmatically speaking, it can be a bit difficult when the rubber meets the road and you have to make annoying concessions in order to get the job done with regard to a particular service provider.


Just musing,

-Todd


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Tuesday, July 02, 2019 8:24 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: common LDAP schemas to draw attribute definitions from

On 7/2/19, 9:11 AM, "Boyd, Todd M." <tmboyd1 at ccis.edu> wrote:

> I think it would also help with figuring out what the heck an 
> attribute is for just by looking at it rather than needing to decipher a URN OID as Nate hinted at.

That's why SAML has a FriendlyName attribute for debugging and ease of identification.

Documentation is fine, but there is nothing that you can put at a URL that any software would ever have any idea what to do with, and nothing that wouldn't work just as well by defining it separately. The value of a URL to software is that information at the URL can change, but that's anathema to the kind of metadata one would have to associate with attributes, which are practically unchangeable if they're used interoperabilty. That's why we have a million identifiers; all the old ones are frozen technically.

> I believe Microsoft is using URL-based attributes for ADFS/SharePoint/etc., though it's using WS-Fed rather than SAML.

They use both, and WS-Federation is SAML 1.1 with different wrapping paper anyway.

But they made the names up and they have no precise technical definition anywhere that I am aware of. They mean whatever a particular person looking at them thinks they mean.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net