A consultation period on the Metadata Registration Practice Statement was opened on Monday 17th November 2014.  A nominal period of 6 weeks would be set for this consultation but due to the vacation period the consultation will close on Friday 2nd January 2015. REFEDS participants are invited to review the proposed template and make suggestions for changes. 

The document for consultation is available as a pdf - line numbers have been switched on for convenience of reference.  Please note that this is intended to be a template document only and that wording proposals are suggestions, not binding.  It is expected that some federations will need to make changes due to local requirements...but federations will be encouraged to follow as close to this format as possible.  Please enter your comments below or to the refeds mailing list. 

Further information on the FOP approach is available. 

Comment #Line NumberCurrent TextProposed TextEditor Notes
 1240 Members of the Federation Operator are eligible to...What is Member of Federation Operator? Does it mean Federation Member? Or Federation operator’s staff? Clarify the example to avoid misunderstandings, people will use copy/paste anyway...Clarify language.
 2240...make use of the Federation Operator’s registrar to register entitiesWhat is Federation Operator’s registrar? The tool to manage SAML2 metadata? Or an individual employed by the federation operator whom the Federation Members can ask to update the metadata? Clarify the example to avoid misunderstandings.Add registrar definition.
 3246The membership process verifies that the prospective member...Clarify the membership process example to avoid misunderstandings. Is this the place where the process is defined? Who is responsible for making the checks in the membership process? The Federation member? The Federation operator? Clarify language - use joining rather than process.
4 249…a number of official databases.Please be explicit in the example to avoid misunderstandings.Not possible - this will need to be defined by the individual federation based on local practice.  Some examples could be given.
5257The member’s canonical name is disclosed in the entity’s <OrganizationName> element.To avoid misunderstandings and confusion, clarify that <OrganizationalName> means a SAML2 metadata element.Add SAML2.
6 270 registrationInstant="2016-11-29T13:39:41Z"Is the registrationInstant attribute the time when this entity was first registered or some of its metadata was last modified?   The MDRPI spec doesn’t make this clear to me…See comments from PS below.
7 310 Ensuring URLs specified in the metadata are technically reachableIf an entityID is a URL, does it need to resolve to a reachable page? Clarify Remove.
8 311 Ensuring protocol endpoints are properly protected with TLS / SSL certificates.    

Where “properly protected” is defined?

 		Further clarity would require the document to need updating too frequently could perhaps refer to standard best practice recs elsewhere?
9315, 322, 324 "Change" vs. "addition, change or removal"There seem to be conflicts in these lines regarding if the initial addition of a new entity is covered by this section at all. Line 324 says entity addition is covered by this section, 322 and 315 talk only about changes Slightly pedantic, has not real impact on meaning. 

 

 

  • No labels

1 Comment

  1. Peter Brand

    Comments to some of the comments, where I seem to have provoked them:

    • 6: Clarification for the MDRPI spec should be sought from OASIS, not from REFEDS. Since all the spec has to say on this is "The instant the entity was registered with the authority." my own interpretation of registrationInstant is that this is the instant that entity's metadata was initially registered. Not "latestChangeInstant".
    • 7: No, entityID is defined as URI. No need to try to "resolve" values even if the URI of choice happens to be a URL. This seems to come from eduID.at's MDRPS section 6.1, where the intention was to not include the entityID, but protocol endpoints, OrgURL, MDUI elements (e.g. PrivacyStatementURL, InformationURL, Logo), etc.pp.
    • 8:  eduID.at's MDRPS section 6.2 is further clarified in 6.3 and 6.4. I don't think you'd want to give more concrete advice on TLS configuration, as that's bound to be out of date the moment you write it down. Unless you do want to prescribe TLS properties ("TLS 1.2 with FPS ciphers", etc.) and are prepared to frequently update this document, and re-evaluate previous registrations.
    • 9:  eduID.at's MDRPS section 3.1 seems to be the source of the problem, feel free to suggest a different section name for 6.1. The major section 6 is neutrally called "Entity Management" and there is no section on entity "addition/registration". My intention was to express the fact from lines 324-325, in my own document I saw no need to repeat that fact seperately for addition/registration vs. change vs. removal.