<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">Am 22.12.2016 um 04:08 schrieb Klingenstein, Nate <<a href="mailto:nklingenstein@calstate.edu" class="">nklingenstein@calstate.edu</a>>:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<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></div></div></blockquote><div>If you abstract from the technical formats of X.509 and SAML EntityDescriptor you end up with a bunch of claims, such as </div><div class="">Entity holds key K, entity controls domain D, entity is operated by organization O, O is registered by X, etc.</div><div><br class=""></div>Both formats hold the implicit assumption that the claims that are of different provenance have been stitched together by the RA/CA respectively the federation operator. The RA/CA and FO are trust brokers, not finally authoritative. Although it is a convenient shortcut to think that the are.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" 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></div></blockquote></div><br class=""><div class="">The notion of „pointing to“ at the level of cert and metadata is a question to be solved later at implementation time. To answer the "hard question“ (what is supposed to be definitive and authoritative) formally correct, a policy needs to be defined for the parties relying on certs and entitydescriptors. To build a model of such a policy you need to decompose the current SAML federation structure, both PKI and SAML-MetaIOP, extract the claims and its assertions, and build a graph where claims are nodes and the assertions are edges. At this point directed associations start to make sense. </div><div class=""><br class=""></div><div class="">- Rainer</div></body></html>