search

erasmus-without-paper / ewp-specs-api-discovery

Specifications of EWP's Discovery API.
MIT License
3 stars 1 forks source link

Please elaborate on the EWP Registry Governance Rules #17

Open umesh-qs opened 2 years ago

umesh-qs commented 2 years ago

I see below details under https://owncloud.erasmuswithoutpaper.eu/index.php/s/zyNXSfU78NMtULf?path=%2F2022-04-06_Infrastructure_Forum#pdfviewer

image

This is not clear to us.

janinamincer-daszkiewicz commented 2 years ago

What exactly is not clear? eduGAIN staff or choosing URL's or how will Dashboard operate?

umesh-qs commented 2 years ago

Why is the distinction? Every institution provides a URL on new registry portal. Shouldn't matter which software is being used.

janinamincer-daszkiewicz commented 2 years ago

Yes and no. In-house software providers know their URLs. 3rd party software providers know URLs of their clients so may deliver them to the Registration Portal. Then HEIs just pick them up from the list.

janinamincer-daszkiewicz commented 2 years ago

There is one more case. Software comes from the 3rd party software provider, but it is installed in HEI's premises. In that case also HEI should deliver URL, as HEI knows where it is installed.

umesh-qs commented 2 years ago

So every HEI in the network will have to add their manifest url in new registry portal, to use EWP services?

janinamincer-daszkiewicz commented 2 years ago

Yes. This is done currently as well but by emails.

umesh-qs commented 2 years ago

what is meant by "Dashboard–register in the Dashboard (after delegation, also switch on/off APIs)"?

janinamincer-daszkiewicz commented 2 years ago

Registration Portal will be integrated with the Dashboard. HEI which is Dashboard client, after choosing Dashboard, will be able to switch on/off APIs straight in the Registration Portal - to improve customer experience.

umesh-qs commented 2 years ago

Why this special privilege only to Dashboard clients?

janinamincer-daszkiewicz commented 2 years ago

Because Dashboard will deliver API for that. All the other providers will also be invited to deliver such API - in the future.

umesh-qs commented 2 years ago

Did we or any other service provider say that we don't want to implement the API? Why not open it and let providers decided when to implement?

janinamincer-daszkiewicz commented 2 years ago

Great to hear such commitment. We still have to design these APIs, they are not yet ready. I describe plans, not a ready system.

umesh-qs commented 2 years ago

Thanks. We are committed to make lives easier for our clients, within the API limitations. I assume your last comment means that API will be open to all and not just Dashboard alone.

janinamincer-daszkiewicz commented 2 years ago

I assume your last comment means that API will be open to all and not just Dashboard alone.

Yes.

georgschermann commented 2 years ago

why an API for switching on/off APIs? thats done in the systems providing the manifests I think as it is done now?

janinamincer-daszkiewicz commented 2 years ago

To allow users to do all governance decisions in one place.

georgschermann commented 2 years ago

then I think it would be - far - easier to manage this directly in the RP, just let them pick one manifest per API, or allow to toggle APIs between the manifest URLs provided or the like, this would mean minimal additional effort for the RP, removing some duplicate checks from the RP (so even less effort) and would not create a whole new API with large implementation / test effort for ALL Providers, specification effort (which may on it self exceed the implementation effort for RP), testing effort, support, etc ...

janinamincer-daszkiewicz commented 2 years ago

There are some good reasons not to do it in the Registration Portal. We may discuss this issue during the extra Infrastructure Forum devoted mainly to the Manifest file. There was not enough time for that on 2022-04-06. This extra one will most probably take place 2022-04-20. I will send a message tomorrow or a day after tomorrow.