The partner has switched to a new provider and has sent Learning Agreements that were in the First Version.

[anant6767]

We have a case where the partner changed providers and then sent us the LA from First version onwards i.e. no changes proposal was present. Is this acceptable? Can they continue to make changes post the first version?

<la:la>
    <la:omobility-id>1GEC7T6I-303P-PH1R-1IEW-9RJE1U2H4ROK</la:omobility-id>
    <la:sending-hei>
      <la:hei-id>xxxxxxxxxxxx</la:hei-id>
      <la:ounit-name>xxxxx </la:ounit-name>
      <la:ounit-id>XXXXX</la:ounit-id>
      <la:contact-person>
        <la:given-names>Kanchana28</la:given-names>
        <la:family-name>28test</la:family-name>
        <la:email>hebib94303@jwsuns.com</la:email>
        <p:phone-number>
          <p:other-format>235</p:other-format>
        </p:phone-number>
      </la:contact-person>
    </la:sending-hei>
    <la:receiving-hei>
      <la:hei-id>yyyyyyyyyyyyy</la:hei-id>
      <la:contact-person>
        <la:given-names>10909NeverInternalContactFN</la:given-names>
        <la:family-name>10909NeverInternalContactLN</la:family-name>
        <la:email>neverewo123@yopamil.com</la:email>
        <p:phone-number>
          <p:other-format>876543</p:other-format>
        </p:phone-number>
      </la:contact-person>
    </la:receiving-hei>
    <la:receiving-academic-year-id>2027/2028</la:receiving-academic-year-id>
    <la:student>
      <la:given-names>values</la:given-names>
      <la:family-name>blank</la:family-name>
      <la:global-id>esitest1212</la:global-id>
      <la:birth-date>1995-05-08</la:birth-date>
      <la:citizenship>AD</la:citizenship>
      <la:gender>1</la:gender>
      <la:email>hanifoci@mailinator.com</la:email>
    </la:student>
    <la:start-date>2024-05-20</la:start-date>
    <la:end-date>2024-09-25</la:end-date>
    <la:eqf-level-studied-at-departure>3</la:eqf-level-studied-at-departure>
    <la:isced-f-code>0031</la:isced-f-code>
    <la:student-language-skill>
      <la:language>BM</la:language>
      <la:cefr-level>B1</la:cefr-level>
    </la:student-language-skill>
    <la:first-version>
      <la:components-studied>
        <la:component>
          <la:los-code>values1</la:los-code>
          <la:title>code</la:title>
          <la:term-id>
            <trm:term-number>2</trm:term-number>
            <trm:total-terms>2</trm:total-terms>
          </la:term-id>
          <la:credit>
            <la:scheme>ects</la:scheme>
            <la:value>0.0</la:value>
          </la:credit>
          <la:short-description>updated descripion</la:short-description>
        </la:component>
      </la:components-studied>
      <la:student-signature>
        <la:timestamp>2024-05-09T11:53:41+00:00</la:timestamp>
        <la:signer-app>Provider1</la:signer-app>
      </la:student-signature>
      <la:sending-hei-signature>
        <la:signer-name>Test</la:signer-name>
        <la:signer-position>ms</la:signer-position>
        <la:signer-email>nanette@yopmail.com</la:signer-email>
        <la:timestamp>2024-05-09T11:45:44+00:00</la:timestamp>
        <la:signer-app>Provider1</la:signer-app>
      </la:sending-hei-signature>
      <la:receiving-hei-signature>
        <la:signer-name>Test </la:signer-name>
        <la:signer-position>tmkoc</la:signer-position>
        <la:signer-email>sudeshna@qs.com</la:signer-email>
        <la:timestamp>2024-05-09T11:54:36+00:00</la:timestamp>
        <la:signer-app>Provider1</la:signer-app>
      </la:receiving-hei-signature>
    </la:first-version>
  </la:la>

Steps

• Sending institution and receiving institution were in Provider 1 and have approved LA to First Version
• Receiving institution changed providers to Provider 2.
• Receiving institution then pulled data. Since SCHAC had not changed, the data was pulled. All signatories show with signer-app as Provider 1 i.e. Provider 2 does not have any approval data.

Question: Can Provider 2 assume that the LA is valid since they do not have the original approval or history?
Question 2: Can this LA be further edited i.e. post first version? Since the sending institution has not changed their provider, they should not have any problems in updating their LA.

[janinamincer-daszkiewicz]

Thank you Anant for creating this issue. Could you please upload here the last version of LA created under the old provider and the first one created under the new provider (of course with anonymised private data). In particular I would like to see which identifiers are reused which allow to recognize this LA as the old one.

[anant6767]

Thank you Anant for creating this issue. Could you please upload here the last version of LA created under the old provider and the first one created under the new provider (of course with anonymised private data). In particular I would like to see which identifiers are reused which allow to recognize this LA as the old one.

Updated the question with example, steps and questions

[janinamincer-daszkiewicz]

Question: Can Provider 2 assume that the LA is valid since they do not have the original approval or history?

Yes. This LA has all three signatures from proper persons. Provider does not matter (from the business point of view).

Question 2: Can this LA be further edited i.e. post first version? Since the sending institution has not changed their provider, they should not have any problems in updating their LA.

Yes, it can.

[anant6767]

but Provider2 will not have any history of the action taken on learning agreement.

[janinamincer-daszkiewicz]

That's true, but will this be a problem? Can you show an example when this will matter.

[anant6767]

How to the receiver knows that the LA received is genuine ?

[janinamincer-daszkiewicz]

Because it comes from the server covering the sending hEI.

[umesh-qs]

What Anant meant is the genuineness of the receiver signature added on the LA by the sending HEI.

[janinamincer-daszkiewicz]

I understand that you mean this part of LA:

    <la:first-version>
      (..)
      <la:receiving-hei-signature>
        <la:signer-name>Test </la:signer-name>
        <la:signer-position>tmkoc</la:signer-position>
        <la:signer-email>sudeshna@qs.com</la:signer-email>
        <la:timestamp>2024-05-09T11:54:36+00:00</la:timestamp>
        <la:signer-app>Provider1</la:signer-app>
      </la:receiving-hei-signature>
    </la:first-version>

'signer-app' where the name of the Provider is given has no business value. If HEI get LA from the proper node, with the proper signer name, position, email, it can assume that this is the valid LA, the same as the one obtained from the other provider. In particular 'signer-app' is optional.
In fact it would be interesting to know if any node processes this field in any way.

[umesh-qs]

I understand that you mean this part of LA:

    <la:first-version>
      (..)
      <la:receiving-hei-signature>
        <la:signer-name>Test </la:signer-name>
        <la:signer-position>tmkoc</la:signer-position>
        <la:signer-email>sudeshna@qs.com</la:signer-email>
        <la:timestamp>2024-05-09T11:54:36+00:00</la:timestamp>
        <la:signer-app>Provider1</la:signer-app>
      </la:receiving-hei-signature>
    </la:first-version>

where the name of the Provider is given has no business value. If HEI get LA from the proper node, with the proper signer name, position, email, it can assume that this is the valid LA, the same as the one obtained from the other provider. In particular is optional. In fact it would be interesting to know if any node processes this field in any way.

Does it mean that the LA can be moved to first version even if receiving institution has not approved, since it is not mandatory?

[janinamincer-daszkiewicz]

Does it mean that the LA can be moved to first version even if receiving institution has not approved, since it is not mandatory?

It is mandatory, only signer-app is not important.

[janinamincer-daszkiewicz]

A reminder: https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/stable-v1/endpoints/get-response.xsd

<xs:complexType name="Signature">
<xs:element name="signer-name" type="xs:string" minOccurs="0" maxOccurs="1">
<xs:element name="signer-position" type="xs:string" minOccurs="0" maxOccurs="1>
<xs:element name="signer-email" type="xs:string" minOccurs="0" maxOccurs="1">
<xs:element name="timestamp" type="xs:dateTime" minOccurs="1" maxOccurs="1">
<xs:element name="signer-app" type="xs:string" minOccurs="0" maxOccurs="1">

[umesh-qs]

Does it mean that the LA can be moved to first version even if receiving institution has not approved, since it is not mandatory?

It is not mandatory, only signer-app is not important.

I am not sure if you have understood the question. Question is how can my system trust that the LA was indeed signed by my client? Anyone in the network can send me a LA claiming that it was signed by me, on so and so date.
If you are implying that there is no need to prove this and it is up to the institutions to deal outside the system, then we will inform our clients accordingly.

[janinamincer-daszkiewicz]

I am not sure if you have understood the question.
Most probably I have not, as I do not see an issue here (yet)

Question is how can my system trust that the LA was indeed signed by my client? Anyone in the network can send me a LA claiming that it was signed by me, on so and so date.

This is not anyone. This is the provider who represents your partner. I do not see any added value in the signer-app having any particular value. Anyone can put any value there or leave it empty.

If you are implying that there is no need to prove this and it is up to the institutions to deal outside the system, then we will inform our clients accordingly.

To prove what and how? I just do not follow :(
Please show a scenario when something bad happens.

[umesh-qs]

I am not sure if you have understood the question.
Most probably I have not, as I do not see an issue here (yet)

Question is how can my system trust that the LA was indeed signed by my client? Anyone in the network can send me a LA claiming that it was signed by me, on so and so date.

This is not anyone. This is the provider who represents your partner. I do not see any added value in the signer-app having any particular value. Anyone can put any value there or leave it empty.

If you are implying that there is no need to prove this and it is up to the institutions to deal outside the system, then we will inform our clients accordingly.

To prove what and how? I just do not follow :( Please show a scenario when something bad happens.

As I understand, no proof of any sort is needed in terms of whether receiving institution has signed the LA or nor, as long as sending institution is claiming that the receiving institution signed it on a particular date. Thanks for confirming. We will follow that. This thread can be closed.

[janinamincer-daszkiewicz]

Please show a scenario when something bad happens.

[janinamincer-daszkiewicz]

Receiving HEI knows whether it has approved LA under Provider 1, this knowledge is moved to Provider 2, so Receiving HEI still knows that LA has been approved.

[janinamincer-daszkiewicz]

This is one of the issues to discus within the general Data Portability context. I will raise it during the IF meeting on 2024-07-17.