...
Alan & Pal: Then it should be possible to do MUST MDUI:displayName
Alans Notes
homework -
Alex and Jon from UKAMF have looked at the IdP requirements in Baseline
cannot be lifted over....
Miro - lower eduGAIN baseline...federations can be tighter
Alan - the baseline should be no looser than the lowest federation 'tightness'
"The IdP is operated with organizational-level authority" - will ned to work on the wording here. what about
IdPs operated by a service/3rd party - okay if thats with the authority of the organisation. SWAMID covers
this with their policy - maybe polices can be used. what about the federation federation metadata? - doesnt
yet exist but vetting could be shown in the form of flags/enums for processes followed
institutions with multiple IdPs - someone of a senior enough level can get it into the federation. how to check
or confirm its authorised?
"The IdP is trusted enough to be used to access the organization’s own systems" - Alex - 'what about smaller colleges
who have an IdP to access external SPs but not an SP of their own to use with the IdP' . perhaps re-wording
or phrasing such that 'IF you had a service, would you trust/use this IdP for access? '
"Generally-accepted security practices are applied to the IdP" - still have someway to go to define federated security
practices but this statement didnt have any noted contention
"Federation metadata is accurate, complete, and includes site technical, admin, and security contacts, MDUI information, and privacy policy URL"
SAML2Int only requires SPs to have this. most were okay with SPs in this way right now
UK does not have privacy policy URL for their IdPs (well, they have for 2. so thats pretty much none) - other federation
particpants think this is okay and doable...buut maybe other things like CoCoV2 etc will sort this out ?
as for other elements
'admin' - the UK treats this as the admin user who has the authority to request/change federation data and does not publish this.
technical/support contacts - looks do-able but may need to adjust the requirements to not be a single indiviuidual persons
address but an address that can be receoved by one or more people or a service desk solution etc (to ensure contactability.
security contact - pre SIRTFI this could be filled but if its filled its not a statement of SIRTFI compliance (that requires
the entity category too) - but most federation operators said manny of their institutions havent got their services tightly
intergrated into IT security process/involvement. whats about 3rd parties who manage the service?
discussion of MDUI information - logo requirement not too bad but other fields need looking at.
only a few entities in eduGAIN appeared to not have a DisplayName - so thats a pretty solid possibility
(but in eduGAIN SAML profile its only a SHOULD - we can maybe get that to a MUST to go with this baseline?
Description etc - what about language? we can currently only recommend language of the region and English(?) as
a secondary ?
URLs - problematic and will need efforts.
discussion stopped just before going into SP requirements in the baseline.