Using URLs vs. URN OIDs: best practice?

[Cantor, Scott]

> We are considering two options for the new names:
> 
> 1. Use our OID, as in "urn:oid:1.x.x.x.x.x.x"

They shouldn't really need to be *your* OID. If it's a standard LDAP attribute from a widely adopted schema, you should have an OID from an external source and that is what should be used in SAML. I don't agree with any of the arguments against that because all of them amount to pointless name bikeshedding that is completely dispensed with by usng the OID. That trumps every advantage of the alternatives for me.

For purely local attributes, even if they end up in LDAP incidentally, I would use whatever URL or URN style one prefers from a local namespace. I use URNs for consistency with how I started doing it years ago, but if I didn't have a urn:mace:osu.edu namespace already, I doubt I'd get one now. But the minute I got an argument from anybody about the name of an attribute, out comes the OID. I will not spend a solitary second on that stupidity.

> The second format has a couple of obvious examples: it is easier to see from
> the name what the attribute is and, as the name is a URL, we can set it up so
> that going to that URL displays the documentation on that attribute.

That does nothing useful in practice, nobody's clicking a link in a log file.

> Before embarking on this large change, I wanted to know if there are any
> advantages to using the "urn:oid" over the URL? Remember, that right now
> for several of our attributes we are using _neither_.

The advantage is not having this conversation unnecessarily, and that's why it beats all the alternatives. But I have never had much trouble just assigning the names I choose to assign. That might be due to the fact we use the Shibboleth SP for the most part so I just give them the example mappings to use.

-- Scott