Multiple Schacs per HEI or manifests on ounit level

[georgschermann]

Since this issue became more urgent for us as we are currently setting up about 100 "independet" faculties for EWP I open an issue for discussion here.

This problem was already identified in 2016 but this was prior to the EWP Dashboard, so the chances that faculties were splitted across different providers was smaller, as was my insight on this issue.

First of these cases started to pop up when one facutly registered for e.g. the EWP Dashboard and other faculties couldn't use it or used other providers, with one mention here.

It was also already discussed when the ECHE list checks and Erasmus Code duplicate checks were introduced, since we already had some of these cases in the network, but those could be resolved otherwise.

It is also mentioned in regards of the ounit ids on the IIAs here.

I am not aware how far the EWP team and DG EAC has come in this regard @janinamincer-daszkiewicz?

It has quite a lot of implications on the registry, governance and local implementations

Our earliest approach to this was simply to use sub-schac like faculty1.schac1.tld and faculty2.schac1.tld, quite easy but no longer possible with the ECHE/EC checks and not ideal for auto-discovery of partners. I think this would still be the best approach for this, since all other solutions I can think of seem unfeasible.

There are a few possible non-exclusive, non-exhaustive approaches to make this work in the network: The uniqueness of other-ids (PIC, Erasmus Code) could be removed and in case of multiple hits for an Erasmus Code, faculty checks could be made mandatory. If multiple schacs are defined for the own other-ids, hosts could be required to forward/discard/bounce requests they think they were not the correct recipient. The requirement for specific other-ids could be dropped (no Erasmus Code needed, difficult lookup, also suitable in the future for UK, CH (already in the network with "fake" ECs) so probalby a non-issue, NON-EU Heis) A new other-id could be introduced to link the "parent-schac" and enable lookups of faculties. I would not allow for fake Erasmus Codes within one HEI

Looking forward to diskussing and solving this issue.

[umesh-qs]

Since this issue became more urgent for us as we are currently setting up about 100 "independet" faculties for EWP I open an issue for discussion here.

This problem was already identified in 2016 but this was prior to the EWP Dashboard, so the chances that faculties were splitted across different providers was smaller, as was my insight on this issue.

First of these cases started to pop up when one facutly registered for e.g. the EWP Dashboard and other faculties couldn't use it or used other providers, with one mention here.

It was also already discussed when the ECHE list checks and Erasmus Code duplicate checks were introduced, since we already had some of these cases in the network, but those could be resolved otherwise.

It is also mentioned in regards of the ounit ids on the IIAs here.

I am not aware how far the EWP team and DG EAC has come in this regard @janinamincer-daszkiewicz?

It has quite a lot of implications on the registry, governance and local implementations

Our earliest approach to this was simply to use sub-schac like faculty1.schac1.tld and faculty2.schac1.tld, quite easy but no longer possible with the ECHE/EC checks and not ideal for auto-discovery of partners. I think this would still be the best approach for this, since all other solutions I can think of seem unfeasible.

There are a few possible non-exclusive, non-exhaustive approaches to make this work in the network: The uniqueness of other-ids (PIC, Erasmus Code) could be removed and in case of multiple hits for an Erasmus Code, faculty checks could be made mandatory. If multiple schacs are defined for the own other-ids, hosts could be required to forward/discard/bounce requests they think they were not the correct recipient. The requirement for specific other-ids could be dropped (no Erasmus Code needed, difficult lookup, also suitable in the future for UK, CH (already in the network with "fake" ECs) so probalby a non-issue, NON-EU Heis) A new other-id could be introduced to link the "parent-schac" and enable lookups of faculties. I would not allow for fake Erasmus Codes within one HEI

Looking forward to diskussing and solving this issue.

@georgschermann I do understand the problem, but what is the urgency? What you are suggesting/requesting has a huge impact and need time for discussion and then making individual provider systems compatible with it.

[janinamincer-daszkiewicz]

I am not aware how far the EWP team and DG EAC has come in this regard

Not far but my personal opinion is that this is not a proper direction. Being part of the really large university, being in daily contact with many other large universities I really do not understand why one central solution is not chosen and deployed. This is just the organizational issue which for sure can be resolved. What are the merits for HEI to have more than one system, more than one node in the network, more than one solution to learn and maintain? If EU decided to treat HEI as one unit and assign one PIC, one Erasmus code, one OID, why there should be more than one node in the EWP network? It will definitely not help in communication with the partners.

[georgschermann]

@georgschermann I do understand the problem, but what is the urgency? What you are suggesting/requesting has a huge impact and need time for discussion and then making individual provider systems compatible with it.

became more urgent for us as we are currently setting up about 100 "independet" faculties for EWP

It has quite a lot of implications on the registry, governance and local implementations

I am aware of the impact of such a change, we currently have about 50 heis/faculties which cannot use EWP because another part/faculty of their hei uses EWP with another provider, as said if one representative from any part of the HEI registers for the EWP Dashboard even for a quick test or something like that, all other parts of the hei cannot easily use EWP any more.

@janinamincer-daszkiewicz I am also aware that this could be solved 100-1000 fold on organizational level but this seems impossible for some HEIs as per our feedback. There are a lot of decentralized Universities, especially when it comes to general universities which cover medicine, arts, law, education, technical faculties and more, which often come with different requirements for software systems. They often span multiple campuses. And none of the faculties usually have the political/legal power to push a solution onto the other faculties. I would have to check with our clients for some examples, but a quick google search showed e.g. the University of Hamburg with 7? different International Offices, and the medical faculty being a separate legal entity (it seems).

What are the merits for HEI to have more than one system, more than one node in the network, more than one solution to learn and maintain?

This is not the case from HEI/faculty perspective, since they all only have one system, just not the same.

[janinamincer-daszkiewicz]

All these institutions have one rector, a legal authority.

[umesh-qs]

I would not allow for fake Erasmus Codes within one HEI

@georgschermann can you please elaborate on what you mean by this and who is doing that?

[georgschermann]

I would not allow for fake Erasmus Codes within one HEI

can you please elaborate on what you mean by this and who is doing that?

currenty no one does it as far as I know, prior to the big registry clean up, there were several faculties with own schac and fake erasmus code

with fake erasmus code I mean codes not listed in ECHE or otherwise officially granted, as it is currently the case for alls swiss HEIs in the network I think, which doesn't cause any issues at all. But if used within one HEI I think this would cause problems for the schac lookup.

So such HEIs should not happen: HEI uni.at with A CITY01 HEI fac.uni.at with A CITY01X

[georgschermann]

during our community event we did a survey on this topic with following results: 74 respndants so far 15 of 74 (20%) have distributed institutions with different EWP providers within the schac holder 9 of 15 have access to their registered EWP provider and so have to use different systems for daily work 6 of 15 have no access to their registered EWP provider and currently can't use EWP, even though their own system is ready to connect or already connected to EWP

[janinamincer-daszkiewicz]

15 of 74 (20%) have distributed institutions with different EWP providers within the schac holder

The question is why do they do this to themselves. Anyway, as to my knowledge DE EAC is already aware of this situation.