eduGAIN was established with the intention of being broadly technology / protocol agnostic as a framework, but its primary focus as a interfederation metadata exchange point for SAML metadata heavily influenced the direction of its policy development.  eduGAIN is now being asked to consider accepting different technologies with different trust broker approaches into its policy framework and trust fabric (e.g. "Moonshot", GÉANT Trust Broker, OIDC etc.).  If this is to be accepted, changes to the documents will need to be made.  The table below shows the broad changes that would need to be made if this approach was to be accepted by the eduGAIN SG. 

 

DocumentComments
eduGAIN DeclarationThe eduGAIN Declaration achieves the goal of being broadly agnostic and the language used in this should be reflected throughout the document suite (e.g. AAI endpoints).  The use of the term "federation" as equal to joining organisation may need further discussion (most federations don't exist as legal entities). 
eduGAIN constitution

The constitution is heavily based on the assumption of use of SAML and use of the MDS as the trust broker.  Two options exist here: have a constitution per technology / operational model OR update the constitution to reflect a more agnostic approach.  If the constitution is to be updated, the following issues would need to be address:

  • Terminology / glossary review.  Particularly around the use of the term "federation" and proposed new use cases. 
  • Use of SAML terminology in the document - this should be changed to refer to the relevant technology profile.  May want to consider reducing existing profiles in to one technology profile and moving CoCo profile to a best practice document status. 
  • Role of operational team.  Current constitution envisages one operational team with responsibility for "eduGAIN" - how does this fit with the proposed model?
  • Include references to trust broker.  The MDS as a trust broker is not mentioned at all in the current documentation - it is implicit that this forms the core of operation. If multiple approaches are to be used it is essential that this element is called out in appropriate document.  The eduGAIN "practice statement" is mentioned in several documents but has not been written, this will be essential if different approaches are to be introduced. 
  • Appropriateness of current SG model.  SG representatives tend to currently be from SAML federations - will this allow the right representation for multiple technology approach?

CHANGES TO SG: Federations should ensure that representatives can represent all technology profiles.  Federations may vote on all constitutional changes and new profiles but my only vote on changes to technical profiles they use.  Delete bullet 7.

CHANGES TO EXEC: The edugain executive comprises representatives from organisations that fund edugain operations.  The current exective is documented (on the edugain website).   Change bullet 2 to changes to service scope and cost of service changes.   Add designate an edugain operator as a bullet.

Add Federation Operator definition.

A document highlighting areas where the constitution would need to change is available: https://docs.google.com/document/d/1zqq1BRloo0gwxnNtX0X189sMXbODTflLKJzzOxYui34/edit.  This is not intended to be a proposed amended document for ratification, but simply highlights the problem areas.

eduGAIN metadata profile, attribute profile, SAML 2.0 WebSSO profile.These documents are all explicitly SAML profiles - may be cleaner to move these into one SAML profile document and replicate with "moonshot" profile etc. etc. 
GÉANT Data Protection Code of Conduct

The CoCo is for SAML implementations only and its current status is a bit unclear and causes some confusion, particularly as it is broadly about entity implementation and blurs the lines between instructions to federations / instructions to entities. 

May be better to pull this out into a section of "best practice endorsed by eduGAIN SG" OR point specifically to documentation for how federations should implement CoCo. 

  • No labels

4 Comments

  1. Mikael Linden

    These documents are all explicitly SAML profiles

     

    True for the others, but the Attribute profile has only few SAML-dependencies (reference to representation of attributes on SAML2, SAML2 Persistent ID).

    One of the issues for Relying parties is the heterogeneous/conflicting attribute supply of the IdPs. Having only one improved attribute profile would make it stronger and more widely supported. Especially if the alternative is to have several conflicting attribute profiles for different technologies.

  2. Mikael Linden

    The CoCo is for SAML implementations only

    Oh, it isn't for SAML only. The core document (GEANT Data protection Code of Conduct for SPs) is technology agnostic. The two other normative documents (Entity category definition and SAML2 metadata profile) mount the first one on SAML2 WebSSO, but it can be mounted on other technologies (like Moonshot or OIC) as well. The same applies for the supplementing documents.

  3. Mikael Linden

    blurs the lines between instructions to federations / instructions to entities

    I think the documents articulate quite clearly the responsibilities for SPs ("GEANT CoCo for SPs") and the responsibilities of the federations ("Operator guidelines").

  4. Nicole Harris

    This isn't a comment on the CoCo documents but on how it has been represented and linked from the eduGAIN site, without enough supporting context and only to the normative documents rather than the more detailed wiki info.