Skip to Content.
Sympa Menu

subject-id-guidance-wg - RE: Asynchronous work - IDP guidance

Subject: InCommon SAML Subject Identifiers Deployment Guidance Working Group

List archive

RE: Asynchronous work - IDP guidance


Chronological Thread 
  • From: "Boomer, Joanne" <>
  • To: "Jones, Mark B" <>, "" <>, "Morgan, Andrew J" <>
  • Cc: IAM David Bantz <>, "" <>
  • Subject: RE: Asynchronous work - IDP guidance
  • Date: Mon, 26 Aug 2024 14:36:44 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=missouri.edu; dmarc=pass action=none header.from=missouri.edu; dkim=pass header.d=missouri.edu; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=pLQpGs4SK9ULtkb7wyoCHV/pRrte7fcGT6De3WLQp6A=; b=wu2ZNKvwdTaBmu3Pl1UOuPuDS9NTCwNiRSXwEUPpG80+79UeMeIwKULj+kij/tO6FA2paDWh86rPxH2ASOmHXwLLfNUp7FQanz2CoI2wdILl8njKtbOPZH+X1vcmSviH/OYtsPMKfPi19YZWlya81BJvilgua2OYqE78dKvyeYZaHYbk9AX6qCsqKnBcjfBjOs39oBu9CCb0/KN9aHJCLuR++kQzUTeSxQvR4pTvTdFdBt1/qId8G00VnByYozuoR2Dnhaz40Gq9sCRycfj3zTCCDaM/vzmVOB6xE3P3ggu5BYxZhOnLyTs64nKtP4JatUDqlenNLdlbScL7u5oJXA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=b1xC1kFydJEvrDaLb6A45NxYuNv+P+bGygYNI7irNLBvvUwvkn6k2UpZXPlwh8VlSC2++hJcGUTH6Ak1JC1hJo7f5x+0fYCq98jR6obLD+iBw4qRvollceZ6mJhGN4I4HShnbeLLcw7qOqE3VoALqTIEVAKPUoUpQeOcvyy/NQ3HJPeBQtB4/RBoZfwWLd6X7UiaV+QpxF7/k3+tswBQlZu5rP/aFJTkC1EiyEZxOPYRecRMGvaSI3OWaIXAasWuSICPtg/a6eL4R1dQyqyEk1C54zXeTv3edRTbnVb/1pbe+uRmhyZ+QUm+OIcdt7caLluVH9OqLUipl0jmR7o2JA==

The other part of the discussion included if you were a ‘new’ IdP and having to setup both subject-id and EPPN for the first time.  I wondered if our recommendation should be to use the same value for EPPN as Subject ID, but as Mark points out below there was discussion on how there is an unspoken expectation that EPPN is human readable, so subject-id may not be a great idea in that scenario.

Joanne

 

From: <> On Behalf Of "Jones, Mark B"
Sent: Monday, August 26, 2024 8:22 AM
To: <>; Morgan, Andrew J <>
Cc: IAM David Bantz <>;
Subject: RE: Asynchronous work - IDP guidance

 

WARNING: This message has originated from an External Source. This may be a phishing expedition that can result in unauthorized access to our IT System. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.

In my opinion, the discussion thus far is suggestive that EPPN needs to be replaced.

 

I don’t think that is the correct perspective.

A “Subject ID”, as defined in the working document, is “long-lived, non-reassignable, and omni-directional”.

EPPN, being name based, is only one out of the three.

 

If you are currently using EPPN for a use case that calls for a “long-lived, non-reassignable, omni-directional” identifier, then by moving to using Subject ID you are not looking at a ‘migration’, you are FIXING your process such that it uses a proper identifier type.

 

If you are currently using EPPN for a use case that calls for a human friendly, currently valid identifier, then EPPN may be what you want to keep using.  In fact, moving to use Subject ID could break what you are doing.

 

Subject ID and EPPN are not equivalent.  One cannot replace the other.

 

 

From: <>
Sent: Sunday, August 25, 2024 5:41 PM
To: Morgan, Andrew J <>
Cc: Jones, Mark B <>; IAM David Bantz <>;
Subject: Re: Asynchronous work - IDP guidance

 

External: Increase caution when handling links and attachments.

 

Sunday musings…

 

Near term goal IMO should be rapid adoption of samlSubjectID as good practice for new SP-IdP integrations, replacing reliance on ePPN, uid, mail or other common choices.

 

Revising release policies for existing integrations at this point would be a very difficult sell IMO; hard for me to imagine many SPs or IdPs devoting resources to that. Perhaps at some future time when widely deployed with track record of avoiding issues of other identifiers.

 

If we do want to include transition advice, first topic would be screening questions to determine which integrations merit the pain of revising attribute release and consumption policies. And that screening would have to consider at least existing identifiers uid and mail and nameID in Subject as well as ePPN, IMO. 

 

 

 

On Aug 23, 2024, at 20:16, Morgan, Andrew J <> wrote:



That is correct - EPPN values are not suitable for subject-id values.

 

What guidance do we give to IDP operators that are currently releasing EPPN?  Assume they have already determined the value to release for subject-id.  Should they stop releasing EPPN and release subject-id instead or should there be a period of overlap when both values are released?  What about the access entity categories?

 

This discussion is not about migrating EPPN values into subject-id.  It is about how to start using subject-id and stop using EPPN and other identifiers.

 

Thanks,

Andy

 


From: Jones, Mark B <>
Sent: Friday, August 23, 2024 4:44 PM
To: IAM David Bantz <>; Morgan, Andrew J <>; <>
Subject: Re: Asynchronous work - IDP guidance

 

[This email originated from outside of OSU. Use caution with links and attachments.]

+1


From: <> on behalf of IAM David Bantz <>
Sent: Friday, August 23, 2024 6:28 PM
To: Morgan, Andrew J <>
Cc: <>
Subject: Re: Asynchronous work - IDP guidance

 

External: Increase caution when handling links and attachments.

 

I was surprised to read discussion of migration strategy from eduPersonPrincipalName to samlSubjectID.

My impression is that ePPN is generally name-based, thus not really persistent, thus inappropriate for samlSubjectID. 

David

 

On Fri, Aug 23, 2024 at 9:06 AM Morgan, Andrew J <> wrote:

Hi everyone,

 

During today's meeting, we started discussing implementation guidance for IDPs.  Please read the meeting notes (https://docs.google.com/document/d/1YINTg3Tvjdmx_2HpNs4pdFmL3iHYXGKZBefRxDm3QQ4/edit#heading=h.mrl26y9cootl) and help us develop actual positions and guidance on this topic.  For now, put this at the end of the working document (https://docs.google.com/document/d/1EOVPkPjCs0W6jGFrPwOq6_KMeACma__9WJ71CEeVfYU/edit) under the "Things to Ponder" heading.

 

See you next week!

 

Thanks,

Andy




Archive powered by MHonArc 2.6.24.

Top of Page