Page tree

Versions Compared

Key

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

...

ReferenceCommentProposerActions
Metadata Signing

In order to assure metadata integrity and originality, each federation aggregate MUST be signed as specified in [Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0]. This signature made with the key matching the one supplied to the eduGAIN OT is the only element on which trust is based. In particular the eduGAIN aggregator does not use trust that might be derived from an https endpoint details.

Metadata signature verification is done against the public key alone. If the public key for the channel is supplied in the form of an X.509 certificate, other aspects of the certificate such as its expiry date do not form part of signature verification. This is in accordance with the SAML metadata interoperability profile. In particular an expired certificate will still be used for the verification purpose.


Tomasz W Adopt this proposal
  •   
Metadata Signing

Include the following:

- The signature was made using an explicit ID reference, not an empty reference. - The signature reference refers to the document element. - The signature's digest algorithm is at least as strong as SHA-256. Specifically, MD5 and SHA-1 are not permitted as digest algorithms. - The signature's signature method is RSA with an associated digest at least as strong as SHA-256. Specifically, MD5 and SHA-1 are not permitted as digest algorithms. - The signature's transforms contain only permissible values: -- Enveloped signature -- Exclusive canonicalisation with or without comments


Tomasz WAdopt this proposal
  •   
Terms (Entity)Replace exchanged by published in the following sentence:
"In this document, an Entity refers to an entity’s metadata that a Participant Federation has exchanged through eduGAIN."
Thomas LAdopt this proposal
  •   
Terms (Home Organisation)

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

Thomas LAdopt this proposal
  •   
Terms (eduGAIN Policy Framework)

Typo: SAML Profil  -> SAML Profile

Thomas LAdopt this proposal
  •   
Terms (SAML V2.0)Replace: "Security Markup Language"
with "Security Assertion Markup Language"
Thomas LAdopt this proposal
  •   
Terms (SAML Metadata)Sort this term before SAML Metadata Producer.Thomas LAdopt this proposal
  •   
Terms (SAML Metadata)This requirement should not be hidden in the Terms, but move to '3 Metadata Production":
"Valid SAML Metadata MUST meet the requirements defined in the SAML Metadata Specification [SAMLMeta] including [SAMLMetaErrata]."
Thomas LAdopt this proposal
  •   
Terms (Metadata Registration Practice Statement (MRPS))Drop the second sentence "Every eduGAIN Member Federation must publish an MRPS.". This requirement is alreaedy included in 2 Metadata Registration on line 60. Thomas LAdopt this proposal
  •   
line 65The reference for [REFEDS-MDRPS] is missing.Thomas LAdopt this proposal
  •   
line 84The reference for [SAMLCore] is missing.Thomas LAdopt this proposal
  •   
line 88The reference for [MDRPI] is missing.Thomas LAdopt this proposal
  •   
line 90The reference for [MDUI] is missing.Thomas LAdopt this proposal
  •   
line 103-104Drop "other values in the service's native languages for the elements where appropriate." since it is already mentioned on lines 127-128.Thomas LThis refers to MDUI elements, not md elements
  •   
A general remarkThe current eduGAIN policy is supposed to be technology agnostic, from which it follows that the requirement for the presentation of the federation policy at the moment of joining may be fairly lax. At the moment of enabling a given profile, we should probably require additional documents like a profile-specific part of the federation policy, this should perhaps be mentioned as a required document in the SAML profile?Tomasz Wnot specific to the text consultation
  •   
Metadata registrationI find this somewhat misleading. Other sections of the document refer mostly to how the federation aggregate is produced, signed etc. This section mentions the internal document of a federation which describes how the entities make their way to the federation itself. While I fully support the need to have the registration statement requirement, I would see this particular as an element of something bigger. I would suggest that this section speaks about elements that need to be registered with the OT and which are now mentioned in several places, like the signing key, the registrationAuthority value, the metadata location. This section should state that this information needs to be passed to the OT in a trust preserving way, I would not however specify what this means, this might be specified in the Operations document.Tomasz Wslightly changed wording and added a section on becoming a Federation Participant.
  •   
General questions

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?

Tom BartonAddressed by Tomasz's wording
  •   
Line 111

 line 111 change SHOULD to MUST

Chris Phillips

RegistrationInstant and mdrpi:RegistrationPolicy are only OPTIONAL within the RPI spec so current proposal is consistent. This is because old entities will not have this data.

md:OrganizationDisplayName   can be advanced to a MUST.

  •   
Key rollover

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.

Chris PhillipsInformation for the OPS team, not relevant to this consultation. 
  •   
Scopes

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

There are few legitimate uses of regexp scopes that even UKf accepts. IMO it's a SHOULD. One should have no worries about the entity being silently discarded somewhere if it violates a SHOULD.

Actually the Scope element is only a subset of the issue of using internet domain names in metadata.

Domain names are significant (in terms of security):

* entityIDs

* endpoint URLs

* scopes

I'd suggest to include a more generic section about using domain names in metadata, and include the special requirement of Scope's not being a regexp here.

Chris Phillips

Kristof Bajnok


  •   
ECP and logout

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.

Chris PhillipsNo consensus on adding this at this time.
  •   
BCP recommendations
  • 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
Chris PhillipsInformation for future
  •   

Remove requirement for the element md: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".)

Peter SchoberAdopt this proposal
  •   

Remove requirement/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.

Peter SchoberAdopt this proposal
  •   
Metadata Production

The profile pulls in MetaIOP in the section on "Metadata Production": "Whatever is specified as a MUST in the SAML V2.0 Metadata Interoperability Profile should also be considered as REQUIRED within this eduGAIN Metadata Profile." But that's a rather tall order, because MetaIOP also days (lines 271-273): "Any <md:RoleDescriptor> element (or any derived element or type) appearing in the metadata instance MUST conform to this profile's requirements." But certain implementations are simply incapable or satisfying MetaIOP, such as MS-ADFS in some version(s), e.g. wrt use of expired keys, or the issue with one key not being able to be part of two EntityDescriptors, etc. So by joining eduGAIN as a Metadata Producer all now MUST support MetaIOP (which is of course a good thing, as that's the basis for our trust model), but that would actually prevent MS-ADFS and other lesser implementations from participating. (I.e., they wouldn't be allowed into a federation's upstream feed.)

Peter Schober

References

References should be sorted alphabetically. Glossary could be further trimmed (but sometimes expanded for brevity, e.g. define "Metadata" to mean SAML 2.0 Metadata and only use "Metadata" in the rest of the doc, should save dozens of instances of "SAML Metadata").

Peter Schober

lines 236-239

The paragraph on lines 236-239 re-stating what MetaIOP says anyway for any metadata consumer (so definitively also applicable to the MDS) needs some work (or be replaced with text from MetaIOP).

Peter Schober


Make terminology consistentPeter Schober


Some parts don't make any sense currently (references to SAML namespaces, but without prefixes) and if those can be removed a good part of the Glossary and/or References section can be removed, too, since the terms or references will be unused throughout the rest of the document.

Peter Schober


Do we need to include registrationInstant?Pål Axelsson


Remove information on<mdrpi:PublicationPath>

Chris / Peter



Line 251

Line 251: suggestion: alter ‘SAML Metadata set’ to ‘SAML Metadata export set’ 

Chris Phillips

Add

All entity information provided to eduGAIN is considered public information

Chris Phillips


I was looking into the Metadata Interoperability Profile. While the document refers to 2.0, it seems that it is a not really published draft. I think we should stick to the community specification 1.0, which is not at all different from 2.0. I wanted to provide some minimal corrections to the relevant paragraph, but it's still on my todo.

Kristof B


I vaguely remember a discussion about dropping the requirement of providing Organization elements in English. I don't remember the outcome, nor I fully understand the sentence "<md:Organization> with values in English other values in the service's native languages for the elements where appropriate." I feel to miss a conjunction between "English" and "other values".

Kristof B


Instead of the sentence about validUntil, I'd recommend the following amended paragraph: "A validUntil attribute with a value not later than 2304 hours (28 days) after the creationInstant. Under normal operation conditions the validUntil attribute SHOULD refer to a time not earlier than 72 hours (3 days) after creationInstant." (5->3!)

Kristof B

...

eduGAIN SAML Profile Review - the Long Read

...