Skip to Content.
Sympa Menu

shibboleth-dev - RE: [inqueue-support] InQueue Service Provider Application

Subject: Shibboleth Developers

List archive

RE: [inqueue-support] InQueue Service Provider Application


Chronological Thread 
  • From: "RL 'Bob' Morgan" <>
  • To: Scott Cantor <>
  • Cc: Shibboleth Dev Team <>, InQueue Support <>
  • Subject: RE: [inqueue-support] InQueue Service Provider Application
  • Date: Fri, 16 Jul 2004 10:33:07 -0700 (PDT)


> All I suggested is you use a name that has a more abstract meaning than
> a hostname. I used this example a while back...if OSU wanted to export
> our DSpace service to the world, but it was running on a box named
> "frobnitz", I would use a providerId like
> https://dspace.osu.edu/shibboleth or perhaps
> urn:mace:osu.edu:shibboleth:dspace
>
> Of course, in reality, any real DSpace service would already have a
> reserved alias in the DNS and wouldn't be accessed using a physical host
> name anyway. So it goes with just about any commercial SP.

Yes, this is exactly the point. In any normal case, the name to use
shouldn't be some new name thought up for the purpose of Shib, it should
be the name that has already been chosen for the service with the
expectation that ordinary human users will see it and have some
understanding of it. We already know how to do this with web-based
services (and others, though the web has the most practice of course).
When we deploy portals, webmail, LMSes, signon hosts, repositories,
widely-used applications, etc, we think up names for them that will go
into documentation, be bookmarked, be talked about, and generally be
long-lived and understandable (and we distinguish those names from
low-level hostnames, which identify boxes). Those are exactly the names
that would go into ARPs at identity provider sites.

Names of identity-providers have the same consideration. We've heard from
some places that want to organize their identity-providing in terms of
abstract concepts that administrators like, such as state-wide systems,
consortia, campus operating units, etc. This is just a bad idea. The
whole point of the leverage we seek with the system is to take advantage
of existing familiar structures. So the provider name in this case also
should be the entity that people (both users and other federation
participants) already recognize. That name may not exist in all cases,
but if a new name is to be established, its use in this context should be
part of establishing it generally, not a one-off just for Shib.

- RL "Bob"




Archive powered by MHonArc 2.6.16.

Top of Page