Why is global-id mandatory in student?

[ipnreddy]

Is there any particular reason global-id is mandatory in student? Many clients have not yet implemented this system and hence may not be able to use LA if this is mandatory. Note: according to XSD "All fields are optional only inside changes-proposal element and required otherwise!" for student element.

[umesh-qs]

Hi @kamil-olszewski-uw @fmapeixoto @georgschermann How are you guys handling this?

cc @jpbacelar

[georgschermann]

I think this is related to the ESI (https://wiki.geant.org/display/SM/European+Student+Identifier), European Student Card Initiative, etc. which aim for a global ID of the student and I think this ESI will be broadly implemented in the next few months (atleast among eduGain participants) and becomes mandatory in the near future.

The global ID can be provided by the Universities (e.g. via SSO) or can be generated in a specific format, theoretically it could also be generated with a custom scope, e.g. the schac of the university and an internal id, if not better known.

[umesh-qs]

I think this is related to the ESI (https://wiki.geant.org/display/SM/European+Student+Identifier), European Student Card Initiative, etc. which aim for a global ID of the student and I think this ESI will be broadly implemented in the next few months (atleast among eduGain participants) and becomes mandatory in the near future.

The global ID can be provided by the Universities (e.g. via SSO) or can be generated in a specific format, theoretically it could also be generated with a custom scope, e.g. the schac of the university and an internal id, if not better known.

Thanks @georgschermann. So are you are generating a unique code automatically based on a specific format or you are letting your clients enter it?

[janinamincer-daszkiewicz]

So are you are generating a unique code automatically based on a specific format or you are letting your clients enter it? Automatically. According to experts, ESI should be handled automatically and not (unnecessarily) exposed to end users. It is also better not to make assumptions on its internal format as it may change in the future.

In the future they may also become mandatory in other APIs (like nominations).

[umesh-qs]

If the format may change in future .. then what was the need to make it mandatory now? Wasn't it better to make it mandatory once there was clarity on this?

[janinamincer-daszkiewicz]

No, because the format doesn't matter. What matters is the uniqueness of the identifer.

[umesh-qs]

ok, if I understand correctly global id value under the global-id tag will change, but some part of it will remain unique?

[janinamincer-daszkiewicz]

Yes, I think so.

[georgschermann]

So are you are generating a unique code automatically based on a specific format or you are letting your clients enter it?

The IDs will be taken from SSO about 80%+ of the time, we provide measures for automatically generating these identifiers with well known formats or user defined ones (format does matter for the esi) and we allow the end users to overwrite the values any time.

At the current time I highly doubt that all student (especially exchange students) will end up with only one ESI, not sure if this may cause any troubles, I didn't have a detailed look at this from the legal/organisational point of view. Theoretically as per the specs you can generate (almost) any number of valid ESIs for a student.

[janinamincer-daszkiewicz]

It shouldn't matter. What matters is that they are unique.

[umesh-qs]

@janinamincer-daszkiewicz So the same student can be represented by a different ESI across the university/department and as long as it is unique in API calls, it is not a cause of concern?

[janinamincer-daszkiewicz]

Rather across various universities. We assume that:

• for our students we generate one ESI based on students' number (so globally unique inside university),
• incoming students will have a unique ESI per mobility, but it may happen that next year they will come from another HEI having different ESI.

[ipnreddy]

ESI specifies the following format in the wiki urn:schac:personalUniqueCode:int:esi:: Here, the 'code' should always be an integer or can we use any alphanumeric value? Wiki: https://wiki.geant.org/display/SM/European+Student+Identifier#:~:text=The%20European%20Student%20Identifier%20is%20globally%20unique%2C%20persistent%2C,the%20student%20while%20he%2Fshe%20is%20on%20student%20mobility

[georgschermann]

@ipnreddy taken from the wiki page you linked:

\<code> is a string that uniquely identifies the student within the scope that it has been issued. It has to satisfy the requirements for strings to be used in URNs according to RFC 2141, sections 2.2 to 2.4.

taken from the RFC and summarized:

\<upper> | \<lower> | \<number> | \<other> | \<reserved> = A-Za-z0-9()+,-.:=@;$_!*'%/?#

personally I would refrain from using the other/reserved character

[serkanUH]

To react to the initial remark of @ipnreddy. The fact that the global-id is required is stated on documentation and not in the xsd fields themselves. ( see below ). This is confusing. We should remain consistency and use minoccurs to indiquate somethng is required or optional.

Evantually you can stipulate the exeption that it is not required in changes-proposal in documentation. ( still not best practice , but better ) Best is to make a second student object like "student-changes-proposal" where you can set the fields optional.

The section describes the student who is being sent for this mobility. **Note: All fields are optional only inside `changes-proposal` element and required otherwise!** Global student identifier. Should follow the specification of the European Student Identifier (https://wiki.geant.org/display/SM/European+Student+Identifier).