Skip to Content.
Sympa Menu

shibboleth-dev - RE: Name for Persistent ID?

Subject: Shibboleth Developers

List archive

RE: Name for Persistent ID?


Chronological Thread 
  • From: Scott Cantor <>
  • To: 'RL 'Bob' Morgan' <>
  • Cc: 'Shib Design Team' <>
  • Subject: RE: Name for Persistent ID?
  • Date: Wed, 16 Jul 2003 10:31:22 -0400
  • Importance: Normal
  • Organization: The Ohio State University

> Hmm. The thing you've implemented is the thing that, say,
> EBSCO would get as a persistent but target-specific (and
> otherwise opaque) ID, so they can do personalization etc,
> right? So by nature this attribute is
> "this-user-for-this-target".

Yes, it's exactly like a Liberty IDPProvidedNameIdentifier. That's one
reason I don't know how much we want to diverge into naming the thing as you
suggest, assuming SAML adopts name federation.

>I guess the idea of a single type kinda bothers as it means the AA is
>responsible for figuring out that when target X asks for that type it gets
>one value, and when target Y asks it gets a different value. Moreover it
>prevents cases where target Z might legitimately be able to be given the
>persistent ID value for target Y.

That's really a higher level set of issues. The AA is responsible because
the plugin I wrote is an AA plugin that relies on nothing else, except
perhaps an LDAP persistent ID attribute. It didn't have to be done that way,
but it's convenient (because the AA is quite frankly the best piece of
software you could use for this, it's bloody fantastic).

Admittedly, if we want a quick way to support persistentID mapping, where
you can request someone else's identifier, using target-specific names
*plus* ARPs does give you some ready to run protocol machinery to rely on,
but in that case, you probably also want to encrypt the resulting identifier
to prevent correlation (see the NameIdentifier Mapping Profile in Liberty
1.2).

>Obviously giving each of these things its own type means many types and
>registrations, which is a lose. And there would have to be a mapping from
>each of these types to connect it to the id-generation code. But I'm
>inclined to think the additional clarity is worth it.

Well, it would be all config time stuff. The AA is flexible and can easily
map a bunch of attribute names to the same generation logic.

My inclination is that we should define a general name for this thing, and
document how people could set up the AA so that if they wanted to support a
simple scenario where one target can request a different target's ID, they
can define an additional "alias" for the attribute.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at

http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--




Archive powered by MHonArc 2.6.16.

Top of Page