Page History

Replace: "The organisation with which the end users are affiliated."
with: "The organisation with which an end user is affiliated."

Typo: SAML Profil  -> SAML Profile

1. The aim of this profile seems to be to improve interop among entities in different federations by means of definng common practices by fed ops and edugain ops. Interop issues can sometimes result from different filtering policies implemented by different federations when they consume edugain metadata. Examples include federation-specific standards for end point scheme (HTTP vs HTTPS) and minimum key length (1024 vs 2048+). Is this profile the right place at which to define eduGain-wide standards for such things? If so, is this the right time to consider doing so in these two instances?

2. Members of federations are advised by their federations' operators to check the signature of their federation metadata to verify its authenticity and integrity. Does eduGain do likewise in the process of aggregating member federations' metadata for redistribution? If not, should it, and if it does not but should, is this profile the right place in which to address that requirement?

 line 111 change SHOULD to MUST

Chris/CAF: No additions specific to key rollover but a request for improved operational state information on the technical.edugain.org website

No specifics to key rollover but it would be useful to have a way to render a time difference for publishing time on the eduGAIN OT website.  

Many federations exhibit latency on republishing stemming from operational practices and offline signing techniques. It would be helpful to know in a dashboard fashion the following:

• Last update of mds.edugain.org
• And per federation last known update of eduGAIN data and time difference since MDS publishing.

This will go a long way in managing expectations of when to expect data to circulate beyond '24-48hrs'. I suggest a simple table view of flag and age difference from MDS so we may know how far we all drift from each other republishing data from the eduGAIN MDS 'creation date'. While this could exist in the 'twisty list' for each federation,  one visual dashboard page of observed latency would be more helpful in this regard.

regex scopes should be permitted and eduGAIN should ensure scopes do not collide when accepting aggregates from Members (see longer notes)

They MAY exist and should be strongly encouraged with 'SHOULD'.  'MUST' would be very hard to do but having 'SHOULD' will keep parity to these features across multiple technologies like OIDC and moonshot. See below for more on this.

• Recommended attributes and mapping across the given attribute profiles
• Vocabulary
• Unique identifier practices
• Entity categories (or mapping within given technology profile to exhibit it)
• Consistent application of scope within the technology profiles
• Security characteristics such as position on logout

Remove requirement for the element md:Organization etc OrganizationURL to have values in English (xml:lang="en"): Some Organisations simply do not have English language web sites and it's beyond our control to mandate one. (Though arguably that falls under the kind of exception allowed by "SHOULD".)

Remove requirement for MDUI description for IdPs - there is nothing useful to add here/recommendation (and the matching check in the eduGAIN validator) for the element mdui:Description for entities of role IDP. (1) Often nothing useful can be put there (values like "IDP of Organisation Foo" are semantically void) and (2) I don't know of any software that makes use of that element.