Attribute definition type for eduPersonTargetedID?
Wessel, Keith
kwessel at illinois.edu
Mon Jul 26 15:27:08 UTC 2021
I would agree, Spencer, that you should stop listing eptid since it sounds like the Shibboleth IdP in the not-too-distant future will stop supporting a way to provide it. With that said, it'll take some time for deployers to move to a version of the IdP that no longer supports it, but to stop encouraging folks to send it in new integrations would make sense.
Thanks for confirming for me that there's a relatively clean way to make this transition on the SP side.
Per Scott's comment about <requestedAttribute>, I don't know how widely used it is, but I know that we're not the only school that releases requested attributes to InCommon participants. If we drop the eptid attribute definition, and since InCommon doesn't support an SP being able to signal their preferred name ID format in metadata, it sounds like we're going to be breaking some things. Maybe the answer here is support for requested name ID format in InCommon metadata. But that's not a topic for this list.
Keith
From: users <users-bounces at shibboleth.net> On Behalf Of Spencer Thomas
Sent: Monday, July 26, 2021 10:16 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Attribute definition type for eduPersonTargetedID?
As the tech admin for an SP that can accept ePTID, I am just a little bit confused. We do not require either name format in our SP metadata, but one of our applications wants a "name ID" value. This is what our support document says:
Attribute Name
Description
Example
urn:oid:1.3.6.1.4.1.5923.1.1.1.10 or urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (persistent-id) REQUIRED
Persistent identifier that provides Artstor (SP) with a unique identifier for the account holder
URL of IdP!SP Entity ID! Unique Identifier
I see that the first one is eduPersonTargetedID). The second one appears to be specifying that we will accept NameID in that format (which could be written a little more clearly, I think).
Our attribute-map.xml has these entries that map both to the same "friendly" name for further processing:
<Attribute name="urn:oid:1.3.6.1.4.1.5923.1.1.1.10" id="persistent-id">
<AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/>
</Attribute>
<Attribute name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" id="persistent-id">
<AttributeDecoder xsi:type="NameIDAttributeDecoder" formatter="$NameQualifier!$SPNameQualifier!$Name" defaultQualifiers="true"/>
</Attribute>
>From this conversation, I think we should stop listing ePTID in our support documentation, although we should continue to recognize it.
>From Scott's comments, it would seem that we don't need to make any changes to our metadata.
--
Spencer Thomas
Technical Architect / JSTOR and Artstor
ITHAKA<https://urldefense.com/v3/__https:/www.ithaka.org/__;!!DZ3fjg!rVkG_uJoE9itazU0Tl9N7GROwvDBhBY5S-_CcVGeNgFHd-Gaf5xpBHwR7kGhV-h0Lw$> / 301 E. Liberty St, Suite 250, Ann Arbor, MI 48104
Email: Spencer.Thomas at ithaka.org<mailto:Spencer.Thomas at ithaka.org>
Voicemail: +1-734-887-7004
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210726/68985379/attachment.htm>
More information about the users
mailing list