<style>
/* Changing the layout to use less space for mobiles */
@media screen and (max-device-width: 480px), screen and (-webkit-min-device-pixel-ratio: 2) {
#email-body { min-width: 30em !important; }
#email-page { padding: 8px !important; }
#email-banner { padding: 8px 8px 0 8px !important; }
#email-avatar { margin: 1px 8px 8px 0 !important; padding: 0 !important; }
#email-fields { padding: 0 8px 8px 8px !important; }
#email-gutter { width: 0 !important; }
}
</style>
<div id="email-body">
<table id="email-wrap" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f0f0f0;color:#000000;width:100%;">
<tr valign="top">
<td id="email-page" style="padding:16px !important;">
<table align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#ffffff;border:1px solid #bbbbbb;color:#000000;width:100%;">
<tr valign="top">
<td bgcolor="#ffffff" style="background-color:#ffffff;color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;line-height:1;"><img src="https://shibboleth.net/images/shib_240x83.png" alt="" style="vertical-align:top;" /></td>
</tr><tr valign="top">
<td id="email-banner" style="padding:32px 32px 0 32px;">
<table align="left" border="0" cellpadding="0" cellspacing="0" width="100%" style="width:100%;">
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;padding:0;">
<img id="email-avatar" src="https://issues.shibboleth.net/jira/secure/useravatar?ownerId=ian%40iay.org.uk&avatarId=10125" alt="" height="48" width="48" border="0" align="left" style="padding:0;margin: 0 16px 16px 0;" />
<div id="email-action" style="padding: 0 0 8px 0;font-size:12px;line-height:18px;">
<a class="user-hover" rel="ian@iay.org.uk" id="email_ian@iay.org.uk" href="https://issues.shibboleth.net/jira/secure/ViewProfile.jspa?name=ian%40iay.org.uk" style="color:#326ca6;">Ian Young</a>
commented on <img src="https://issues.shibboleth.net/jira/images/icons/issuetypes/improvement.png" height="16" width="16" border="0" align="absmiddle" alt="Improvement"> <a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/SSPCPP-642'>SSPCPP-642</a>
</div>
<div id="email-summary" style="font-size:16px;line-height:20px;padding:2px 0 16px 0;">
<a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/SSPCPP-642'><strong>improve generated EncryptionMethod metadata</strong></a>
</div>
</td>
</tr>
</table>
</td>
</tr>
<tr valign="top">
<td id="email-fields" style="padding:0 32px 32px 32px;">
<table border="0" cellpadding="0" cellspacing="0" style="padding:0;text-align:left;width:100%;" width="100%">
<tr valign="top">
<td id="email-gutter" style="width:64px;white-space:nowrap;"></td>
<td>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr valign="top">
<td colspan="2" style="color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;padding:0 0 16px 0;width:100%;">
<div class="comment-block" style="background-color:#edf5ff;border:1px solid #dddddd;color:#000000;padding:12px;"><p>Oh yes, there are two parameters so it's (MGF-with-SHA-X, SHA-Y) for 25 combinations. Oh dear.</p>
<p>To merge in from the dev list conversation, I can see why you'd have wanted to avoid all this by having missing parameters mean unspecified values to be picked by the consumer, and obviously from what you say both the IdP and SP agree on that interpretation. I have two problems though:</p>
<p>(a) I do not read that as a valid interpretation of the actual words that are in the spec. I can see what you're getting at, and I accept that you meant to say this, but I don't think you actually did, even if you squint at the text pretty hard. Obviously this is a matter of opinion. It's also obviously fixable by an errata of some kind.</p>
<p>(b) If the spec <b>did</b> say what you want it to be understood as saying, that would in my mind be in conflict with the XMLSEC 1.1 spec, which is very explicit about what missing parameters mean in this particular case: "If not present, the default of MGF1 with SHA1 is to be used." Obviously the algorithm metadata spec can override that very explicit statement, but I think that would in turn need to be very explicit to avoid the real likelihood that other implementers (if there ever are any) go down the same path of interpretation as I have. I don't see a general "if algorithm parameters are missing, just do what you like" is good enough.</p>
<p>My other concern is the more minor one that I see the point of algorithm metadata as giving the other party information about actual capabilities. I don't see that saying "I support X but you have to pick parameters and I'm not going to clue you in as to what will work" is very helpful in the long run.</p>
<p>So, summary: enumerating everything sucks. Just putting in some things you support and not others also sucks, but provides an explicit migration path. However, the most compact way out probably involves making the algorithm metadata spec much more explicit about this, and I wonder how much work would be required to get that through the process. Having said which, I still have reservations about the general approach but it seems like the least evil alternative.</p></div>
<div style="color:#505050;padding:4px 0 0 0;"> </div>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td><!-- End #email-page -->
</tr>
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:10px;line-height:14px;padding: 0 16px 16px 16px;text-align:center;">
This message is automatically generated by JIRA.<br />
If you think it was sent incorrectly, please contact your JIRA administrators<br />
For more information on JIRA, see: <a style='color:#326ca6;' href='http://www.atlassian.com/software/jira'>http://www.atlassian.com/software/jira</a>
</td>
</tr>
</table><!-- End #email-wrap -->
</div><!-- End #email-body -->