# Central questions:

- Is there an initiative in your country for long term identifiers?
- What should GEANT do to facilitate/push? 

# Several initiatives

## Switzerland, SWITCH & eduID:

SwitchAAI started as full mesh, 10 years ago, worked ok within federation but have seen room for improvement.

Trying to transform federation into more of a central login concept. Users will be able to manage their own identity information themselves, e.g. number, email (verified, periodically), postal address (have also tried verifying).  This data is very closely tied to user; other such as education history is still comingg from universities. When user logs in there will be a cache of this data that is aggregated. Users should be able to link their identities to all institutions where they have been a student etc, plus sometimes there are multiple accounts at single institutions. Possible to allow you continued access to resources. If you have multiple affiliations, there will be a process during login in which you choose your affiliation. It will be easier to support additional technologies; universities outsource the federation aspect, critical service. SWITCHAAI is trusted so this works. There will be a challenging migration process; users shouldn’t have to do much. Currently only architecture is complete; universities will migrate to this at some point. Users will have to be informed in advance and trained for new login page. Challenge with duplicate accounts due to lack of national ID.

 
## Estonia

eduID aimed at secondary education. Contains database portal & php, multi-tenant. When user changes password it is hashed and then encrypted with public key of institution – automatic API queries for changes and all new changes are given encrypted password (once). They already have national IDs that are long lived. Institutions are the owners.

## Norway, UNINETT

National IDs do not solve all problems. Issue with national ID; contains personal data and not applicable for foreign users. Also transition between temporary and permanent ID, plus complication when leaving the country. eduGAIN is usually not good enough to cope with these details. Scope of National IDs is more far reaching than R&E. Can solve issue of foreigners with passport number temporarily.

Dataportal: New service to link federated login with attribute sources. Can link APIs. In pilot one of the most popular APIs was for the directory of courses/lecturers.

# General comments on going user-centric:
 
- How are the SPs expected to fit into this scheme? Somehow they will need to be able to drive the users to the attribute authorities. 
There might not so many changes for SPs if users are within federation. SPs might have to process additional information.

- Other option is linking existing long-lived IDs (such as ORCID); when you start looking at this part it changes for the SPs. Can make life easier since they can use vocabulary and existing infrastructure. 

- This implies that there is a central point that aggregates information. Not sure this is true everywhere. For instance at SWITCH EduID this will  the case.
 
- Transition and bridge between technologies and protocols – can separate the data from the application. Makes adoption easier. But this implies that everything should happen within federation. Otherwise you need some kind of proxy where federation acts as bridge with egov, or something more complicated.

- If this crosses security boundaries then paperwork is required. Should be invisible for end user but still needs to be there. 

- ORCID: long lived ID idea for researchers. Especially for international organisations. Lots of movement in this area.

- From AARC, can include ORCID as an SP and attribute authority in current discussions

- Identifiers need to be shared, pointless to keep them locked up. If I take a unique ID as an SP I cannot push it around. —>
Yes you can, but you cannot publish it. For example, in a distributed service you can certainly share across legal associations. Need for a proper definition of a ‘closed’ system.

- EUDAT, ELIXIR and EGI are looking to create unique IDs maybe with harmonisation within themselves. They take the ID, hash it, scope it and pass it around.

- There will be more than 1 unique identifier – key is linking them together. Whether they are from the same source or different. Keeping track of that is issue (e.g. Oracle key looks totally bizarre so seen as low risk to pass around). Opaque or publicly known identifiers are easier to use.