
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">

<div>

<blockquote type="cite" class="">

<div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The

 contents of the certificate become very relevant, but no longer overlapping nor vague.<span class="Apple-converted-space"> </span></span></div>

</blockquote>

</div>

<br class="">

<div class="">And, particularly, to maintain referential integrity, does:</div>

<div class=""><br class="">

</div>

<div class="">A)  Metadata point to a certificate, as in SAML</div>

<div class="">B)  A certificate point to metadata, as I don't know has been done before</div>

<div class="">C)  Both?</div>

<div class=""><br class="">

</div>

<div class="">I think my answer is B.  The providerId has to be put in the certificate.  For the application, that's the primary identifier.  For the IdP, it's informational, while the hostname is the primary identifier, again to make application implementation

 braindead.</div>

<div class=""><br class="">

</div>

<div class="">Sorry for using the list for this, but I hope it helps you think about pressing deployment problems from a new angle.  Shibboleth as software is protocol-agnostic and a reasonable framework for implementation since it has most of the crucial machinery

 built already.</div>

</body>

</html>