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 Number||Current Text||Proposed Text||Editor Notes|
|1||240||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.|
|2||240||...make use of the Federation Operator’s registrar to register entities||What 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.|
|3||246||The 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.|
|5||257||The 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 reachable||If 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?|
|9||315, 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.|