search

erasmus-without-paper / ewp-specs-api-omobility-las

Learning Agreements
MIT License
1 stars 2 forks source link

When does the caller cover the receiving HEI? #34

Closed jiripetrzelka closed 2 years ago

jiripetrzelka commented 3 years ago

Should we permit access (Index, Get, Update) to the LA to the receiving HEI X in case that:

a) The caller's keyId corresponds to one Host in manifest and this Host covers HEI X but does not implement the server part of the API and none of the other Hosts implement the server part of the API for this HEI X either? -> I suppose Yes.

b) The caller's keyId corresponds to one Host in manifest and this Host covers HEI X but does not implement the server part of the API and another Host in manifest implements the server part of the API and covers HEI X? -> I suppose No.

c) The caller's keyId corresponds to multiple Hosts in manifest and none of them implements the server part of the API and only some of them cover HEI X and no other Host with another KeyId implements the server part of the API for HEI X? -> I suppose Yes.

d) The caller's keyId corresponds to multiple Hosts in manifest and one of them implements the server part of the API but does not cover HEI X, while another Host with the caller's keyId does cover HEI X but does not implement the server part of the API? -> I suppose No.

Am I correct or wrong?

umesh-qs commented 2 years ago

As per the EWP spec as long as the keyId is under host entry covering the HEI X, the caller should be allowed to use the keyId for making calls to any of the partners API, irrespective of whether the host is exposing none, any or all of the APIs.

Not exposing any API should not restrict the host from consuming other hosts API.

So the answer should be yes for the 4 scenarios you have mentioned.

jiripetrzelka commented 2 years ago

Which means, for example, that in scenario b) MoveOn should be allowed to invoke the LA Update endpoint, even if the university decided to use Dashboard for the entire management of LAs, just because MoveOn covers the university in that it provides for example the management of IIAs for the given university.

I see that this design gives quite a lot of flexibility to universities when it comes to switching between for example MoveOn and Dashboard for management of LAs and I suppose that it has been a deliberate design decision to let providers have the responsibility not to invoke data-changing endpoints beyond what is agreed between the provider and the university.

umesh-qs commented 2 years ago

The registry structure does not tell how a University wants to handle data for consumption. It can only define restrictions for exposing the data.

So it is individual service providers responsibility not to invoke APIs when they shouldn't.

sascoms commented 2 years ago

Out of the scope of this issue but: Unfortunately, that flexibility exists in some APIs, especially in IIAs. And I am afraid that will cause content problems in near future, when all HEIs begin to exchange IIAs over EWP.