Re: [Fim4l] [refeds] Deprecating eduPersonTargetedID
Hi all,
as Peter rightly mentioned, FIM4L is a rather new activity that is currently taking up speed and visibility. A first website should be available this week. A charter and a recommendation document are in the making, the latter is still very raw.
Although we see it as a library driven approach with focus on library requirements and standpoints towards scientific publishers (and RA21), the list is open to anyone that wants to contribute to FIM for libraries.
Of course the recommendation document will contain attributes and thus discussions like this thread are relevant for the group. Nevertheless be aware that not all publishers have state of the art SAML SP implementations and providing EPTI might still be necessary for a while. Of course the recommendation document is a good place to push the newer and of course better alternative pairwise-id and we thank Peter S. to bring this up on that list.
Since we are talking about a specification that was finalized this January, we cannot expect adaption in an SP community rather conservative towards software. As the RA21 in its announcement to support Coco mentions "Specifically, the service provider should only ask for eduPersonEntitlement and, optionally, a pseudonymous pairwise user identifier (e.g., eduPersonTargetedID)" we were discussing this on the fim4l list. Such a formulation, also mentioning the SAML subjectID specification and its pairwise-id (as preferred option), is the current idea. If important specifications like eduPerson deprecates EPTI, we might change that as well. But as I said: recommendation is one thing, changing software to consume other IDs another.
BTW: a presentation on FIM4L is planned for the next REFEDS f2f in Tallinn. I am looking forward to that.
Cheers,
Peter G.
Am 22.03.2019 um 15:45 schrieb Peter Schober:
- Peter Schober peter.schober@univie.ac.at [2019-03-22 15:37]:
- Nick Roy nroy@internet2.edu [2019-03-22 15:16]:
What is FIM4L? I agree this recommendation is bad.
Raoul mentioned it here recently: https://lists.refeds.org/sympa/arc/refeds/2019-03/msg00007.html
I found out a bit about it and reported back here: https://lists.refeds.org/sympa/arc/refeds/2019-03/msg00013.html
I've since also discovered (and subscribed to) the mailing list http://lists.daasi.de/listinfo/fim4l
None of this is for me to share but since the above info is all publicly and independently discoverable I guess those of you interested in joining this effort and discussing the essentials of access to institutionally licensed resources could do so, same way I did. It is an effort "by the libraries", though (plus selected institutions and federation folks, seemingly), so I'm probably more tolerated than welcome at this point (and progressively so the more I speak up about such issues ;)).
-peter
On 3/25/19, 5:29 AM, "refeds-request@lists.refeds.org on behalf of Peter Gietz" <refeds-request@lists.refeds.org on behalf of peter.gietz@daasi.de> wrote:
If important specifications like eduPerson deprecates EPTI, we might change that as well. But as I said: recommendation is one thing, changing software to consume other IDs another.
Whatever else you do, please please please do NOT mention ePTID. If you want to avoid "new" approaches, then you should be referencing the persistent NameID Format in SAML, and that's that.
If we need an official "emergency" declaration of some sort from eduPerson's new maintaining authority, then that ought to be the first order of business, and really that’s what PeterS was fundamentally asking about in his first email.
-- Scott
On 25 Mar 2019, at 3:29, Peter Gietz wrote:
Hi all,
as Peter rightly mentioned, FIM4L is a rather new activity that is currently taking up speed and visibility. A first website should be available this week. A charter and a recommendation document are in the making, the latter is still very raw.
Although we see it as a library driven approach with focus on library requirements and standpoints towards scientific publishers (and RA21), the list is open to anyone that wants to contribute to FIM for libraries.
Of course the recommendation document will contain attributes and thus discussions like this thread are relevant for the group. Nevertheless be aware that not all publishers have state of the art SAML SP implementations and providing EPTI might still be necessary for a while. Of course the recommendation document is a good place to push the newer and of course better alternative pairwise-id and we thank Peter S. to bring this up on that list.
Since we are talking about a specification that was finalized this January, we cannot expect adaption in an SP community rather conservative towards software. As the RA21 in its announcement to support Coco mentions "Specifically, the service provider should only ask for eduPersonEntitlement and, optionally, a pseudonymous pairwise user identifier (e.g., eduPersonTargetedID)" we were discussing this on the fim4l list. Such a formulation, also mentioning the SAML subjectID specification and its pairwise-id (as preferred option), is the current idea. If important specifications like eduPerson deprecates EPTI, we might change that as well. But as I said: recommendation is one thing, changing software to consume other IDs another.
Peter G, I’ve subscribed to the FIM4L list. Could you please approve my subscription?
Heather, what is needed to update RA21 to recommend use of the SAML subject identifier (pairwise-id?) instead of eduPersonTargetedID?
Thank you,
Nick
BTW: a presentation on FIM4L is planned for the next REFEDS f2f in Tallinn. I am looking forward to that.
Cheers,
Peter G.
Am 22.03.2019 um 15:45 schrieb Peter Schober:
- Peter Schober peter.schober@univie.ac.at [2019-03-22 15:37]:
- Nick Roy nroy@internet2.edu [2019-03-22 15:16]:
What is FIM4L? I agree this recommendation is bad.
Raoul mentioned it here recently: https://lists.refeds.org/sympa/arc/refeds/2019-03/msg00007.html
I found out a bit about it and reported back here: https://lists.refeds.org/sympa/arc/refeds/2019-03/msg00013.html
I've since also discovered (and subscribed to) the mailing list http://lists.daasi.de/listinfo/fim4l
None of this is for me to share but since the above info is all publicly and independently discoverable I guess those of you interested in joining this effort and discussing the essentials of access to institutionally licensed resources could do so, same way I did. It is an effort "by the libraries", though (plus selected institutions and federation folks, seemingly), so I'm probably more tolerated than welcome at this point (and progressively so the more I speak up about such issues ;)).
-peter
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
Hi Peter S,
could you comment, please, on eduPersonTargetedID as requested attribute at Elsevier SP in eduID.at metadata? -
https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
BR Jiri
On Tue, Mar 26, 2019 at 9:07 AM Nick Roy nroy@internet2.edu wrote:
On 25 Mar 2019, at 3:29, Peter Gietz wrote:
Hi all,
as Peter rightly mentioned, FIM4L is a rather new activity that is currently taking up speed and visibility. A first website should be available this week. A charter and a recommendation document are in the making, the latter is still very raw.
Although we see it as a library driven approach with focus on library requirements and standpoints towards scientific publishers (and RA21), the list is open to anyone that wants to contribute to FIM for libraries.
Of course the recommendation document will contain attributes and thus discussions like this thread are relevant for the group. Nevertheless be aware that not all publishers have state of the art SAML SP implementations and providing EPTI might still be necessary for a while. Of course the recommendation document is a good place to push the newer and of course better alternative pairwise-id and we thank Peter S. to bring this up on that list.
Since we are talking about a specification that was finalized this January, we cannot expect adaption in an SP community rather conservative towards software. As the RA21 in its announcement to support Coco mentions "Specifically, the service provider should only ask for eduPersonEntitlement and, optionally, a pseudonymous pairwise user identifier (e.g., eduPersonTargetedID)" we were discussing this on the fim4l list. Such a formulation, also mentioning the SAML subjectID specification and its pairwise-id (as preferred option), is the current idea. If important specifications like eduPerson deprecates EPTI, we might change that as well. But as I said: recommendation is one thing, changing software to consume other IDs another.
Peter G, I’ve subscribed to the FIM4L list. Could you please approve my subscription?
Heather, what is needed to update RA21 to recommend use of the SAML subject identifier (pairwise-id?) instead of eduPersonTargetedID?
Thank you,
Nick
BTW: a presentation on FIM4L is planned for the next REFEDS f2f in Tallinn. I am looking forward to that.
Cheers,
Peter G.
Am 22.03.2019 um 15:45 schrieb Peter Schober:
- Peter Schober peter.schober@univie.ac.at [2019-03-22 15:37]:
- Nick Roy nroy@internet2.edu [2019-03-22 15:16]:
What is FIM4L? I agree this recommendation is bad.
Raoul mentioned it here recently: https://lists.refeds.org/sympa/arc/refeds/2019-03/msg00007.html
I found out a bit about it and reported back here: https://lists.refeds.org/sympa/arc/refeds/2019-03/msg00013.html
I've since also discovered (and subscribed to) the mailing list http://lists.daasi.de/listinfo/fim4l
None of this is for me to share but since the above info is all publicly and independently discoverable I guess those of you interested in joining this effort and discussing the essentials of access to institutionally licensed resources could do so, same way I did. It is an effort "by the libraries", though (plus selected institutions and federation folks, seemingly), so I'm probably more tolerated than welcome at this point (and progressively so the more I speak up about such issues ;)).
-peter
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-04-05 16:58]:
could you comment, please, on eduPersonTargetedID as requested attribute at Elsevier SP in eduID.at metadata? - https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
What is it you're asking speficically? Why the Elsevier SAML SP as registered in eduID.at lists eduPersonTargetedID as a requested attribute? If no existing SP in the world were still using eduPersonTargetedID we wouldn't be having these discussions, would we? So obviously there are SPs that use ePTID today, even in the federation I operate. If you could clarify what the question is I can try to be more specific, instead of having to guess what contradiction you're looking for (or whatever).
[ Of course looking closer at our metadata you'd see that we also modified our copy to contain a NameIDFormat element with 'persistent' listed first. So any Shibboleth IDP that supported the SAML2 standard NameIDs -- not the eduPerson legacy attribute -- would work with that SP just fine using proper persistent NameIDs. I.e., none of our IDPs have to send eduPersonTargetedID to that SP to make it work.)
In case this is still not clear: The ongoing activity to deprecate eduPersonTargetedID will not magically make it disappear from established SPs, nor will it forbid its continued use. But what it will do is prevent new guideline documents being written such as FIM4L's from claiming to support or establish or adhere to Best Current Practices and international standards while at the same time perpetuating or even recommending use of attributes that should not be used per those very standards.
That's what I'm after: To avoid new standards from being created that cement use of obsolete legacy technology even if that legacy technology is still being used today. (Otherwise why bother?)
-peter
Hi,
thanks a lot comments, Peter. I can see that IdPs in eduID.at still need to release eduPersonTargetedID for Elsevier SP at least.
Have you already tried to encourage Elsevier to request pairwise-id instead of eduPersonTargetedID?
Cheers
Jiri
On Fri, 5 Apr 2019 at 17:37, Peter Schober peter.schober@univie.ac.at wrote:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-04-05 16:58]:
could you comment, please, on eduPersonTargetedID as requested attribute at Elsevier SP in eduID.at metadata? -
https://met.refeds.org/met/entity/https%253A%252F%252Fsdauth.sciencedirect.c...
What is it you're asking speficically? Why the Elsevier SAML SP as registered in eduID.at lists eduPersonTargetedID as a requested attribute? If no existing SP in the world were still using eduPersonTargetedID we wouldn't be having these discussions, would we? So obviously there are SPs that use ePTID today, even in the federation I operate. If you could clarify what the question is I can try to be more specific, instead of having to guess what contradiction you're looking for (or whatever).
[ Of course looking closer at our metadata you'd see that we also modified our copy to contain a NameIDFormat element with 'persistent' listed first. So any Shibboleth IDP that supported the SAML2 standard NameIDs -- not the eduPerson legacy attribute -- would work with that SP just fine using proper persistent NameIDs. I.e., none of our IDPs have to send eduPersonTargetedID to that SP to make it work.)
In case this is still not clear: The ongoing activity to deprecate eduPersonTargetedID will not magically make it disappear from established SPs, nor will it forbid its continued use. But what it will do is prevent new guideline documents being written such as FIM4L's from claiming to support or establish or adhere to Best Current Practices and international standards while at the same time perpetuating or even recommending use of attributes that should not be used per those very standards.
That's what I'm after: To avoid new standards from being created that cement use of obsolete legacy technology even if that legacy technology is still being used today. (Otherwise why bother?)
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
* Jiri Pavlik jiri.pavlik@mzk.cz [2019-04-05 18:08]:
thanks a lot comments, Peter. I can see that IdPs in eduID.at still need to release eduPersonTargetedID for Elsevier SP at least.
No they don't. I just explained why in my previous email. (TL;DR: By sending SAML 2.0 persistent NameIDs instead of sending SAML 2.0 persistent NameIDs wrapped into a legacy SAML Attribute.)
You may be able to find a very small number of other SPs in our metadata that request ePTID but do NOT support persiststent NameIDs at this time, I'd have to check.
Have you already tried to encourage Elsevier to request pairwise-id instead of eduPersonTargetedID?
Doing that would be easier (and have a greater chance of success than zero) if such a request were backed by an international agreement of some kind, say, a guidelines document from a library-driven group with diverse membership, let's call it... FIM4L?
-peter
Hi,
On Fri, Apr 5, 2019 at 6:15 PM Peter Schober peter.schober@univie.ac.at wrote:
- Jiri Pavlik jiri.pavlik@mzk.cz [2019-04-05 18:08]:
thanks a lot comments, Peter. I can see that IdPs in eduID.at still need to release eduPersonTargetedID for Elsevier SP at least.
No they don't. I just explained why in my previous email. (TL;DR: By sending SAML 2.0 persistent NameIDs instead of sending SAML 2.0 persistent NameIDs wrapped into a legacy SAML Attribute.)
I see, great.
You may be able to find a very small number of other SPs in our metadata that request ePTID but do NOT support persiststent NameIDs at this time, I'd have to check.
Have you already tried to encourage Elsevier to request pairwise-id instead of eduPersonTargetedID?
Doing that would be easier (and have a greater chance of success than zero) if such a request were backed by an international agreement of some kind, say, a guidelines document from a library-driven group with diverse membership, let's call it... FIM4L?
Coordinated effort of FIM4L, REFEDS, FOG, eduGAIN would be the best I believe.
Best regards
Jiri
-peter _______________________________________________ FIM4L mailing list FIM4L@lists.daasi.de http://lists.daasi.de/listinfo/fim4l
Teilnehmer (5)
-
Cantor, Scott -
Jiri Pavlik -
Nick Roy -
Peter Gietz -
Peter Schober