Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Talk with Pal, and Mario, trying to start in January

Action: All to let Pal and Mario know their main interests - is possible to change focus from previously assigned.

In details

Pal: Policy

Main milestone due - GDRP white paper late, as law gets official late

On SIRTFI, policy work is at REFEDS, contribute there. On workflows for coordination, work Work together with T2 Lukas, especially with Thomas (T1 policy/security and T2 performance)

 

Mario: Technical

Knows IdP as a Service, as subtask leader, but needs input on statistics and sirtfi technical aspects.

eduGAIN Policy (Nicole+Pal)

...

New in V2: penalties

Federation operaters operators need to review new GDRP

eduGAIN needs to review it as well, some federations cannot review it themselves -> GÉANT can offer help

CoCo V2: workshop was proposed, open workspace greater than GÉANT

...

AARC and REFEDS: Deliverables

Sirtfi: something on how AARC making requirements for how  how to react on incidents, REFEDS will review and adapt at federation level. eduGAIN needs to consider the inter federation level.

Use case Orcid

first or second major incident discussed

one or two IdPs were publishing dublicated ids

-> demonstrated people's attention , coordinating effortson what works what didn't, scope for  coordinating efforts 

In eduGAIN

Incident response: T1 Sirtfi + T2 --> Role?Performance

eduGAIN should be active? different views on that

...

  • poor information and overreaction
  • timezone
  • closed space with federation operators + orcid missing, information mismatch,
  • TLP
  • timely? response time
  • not all entities might be in Sirtfi, what with the others?
  • Certs CERTS not always at federation (or none at all) - but other bodies can respond within the process.
  • eduGAIN as service -> make them pay? AH update - not the preferred mechanism. Better to aggregate and fund centrally. Some consideration that a charged service may be possible for things which exceed basic SIRTFI reqs.

Should be careful how we do it, eduGAIN does not check metadata, contact information etc. , eduGAIN is not really managedcurrently. This will need to change.

What should eduGAIN demand from federations and vice versa?

eduGAIN cannot do too much, because of money

Work with REFEDS to coordinate federation and central level response.

If we load too much onto that central function it will increase the central operational costs and the business case of this has to be considered from a cost / benefit perspective. As SIRTFI benefits campuses and SPs, it is considered this case can be made. Similar with performance.

AH/MA note - budget to extend the eduGAIN OT to support communication is ring fenced already.Sirtfi is both ways

Monitoring and Statistics (Miro)

...

Tools: eduGAIN CoCo Monitor Service, Access Check Service, Connectivity Check Service, Attribute Release Check Service, ?? Service

How to deploy tools?

- well documented? repository?

In eduGAIN DNS domain and certificates -> official channels – but what is suitable? Decided by PLM.

Then operations team looks at it and decides if further checks/iprovements (e.g. security) is needed

What next?

  • Sirtfi  tests of timely response of provided contacts - similar for eduroam. Is in use for Trusted Introducer and can be applied.
  • V4/v6 support
  • log https (noClientAuthN) check
  • IdP Name collision dector,
  • https checks?
  • certificate expire warning
  • SSLLabs grade

Not all of these have equal priority - this needs to be determined.

Focus on those which are in eduGAIN BCP and support finding and fixing issues and maintaining current information.

Questions to consider - what happens when federations who are repeatedly informed of issues within their federation and do not demonstrate engagement.