<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><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Am 22.12.2016 um 15:22 schrieb Klingenstein, Nate <<a href="mailto:nklingenstein@calstate.edu" class="">nklingenstein@calstate.edu</a>>:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><br class="">To be honest, the deeper nuances in certificate authoristry are lost on me. I wouldn't know how to take advantage of them, and I live by the convenient shortcut. If you can think of a clever twist there that isn't confusing or hard, I'm eager to learn.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">If you do away with ASN.1 and XML, the resulting data and trust models are quite comparable. I will show an example below.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Whether you call a CA or federation operator a trust broker or a final authority is a little fuzzy to me. I get a signed metadata file or a signed certificate. I have exactly one place to check if it's good. Even in the MDQ model, I have to pick my single authority, from what I understand.</div></div></blockquote><div class=""><br class=""></div><div class="">This is a loose description of an RP’s trust policy: "In CA/FO we trust" (and don’t bother me with the details how they became an authority). But to question the model we need to drill deeper.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">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. <br class=""></blockquote><br class="">Maybe I'm not reading this right, but if I am, I'll need to think about this in more detail before it sinks in. I usually treat claims(in the WS-Trust sense) and assertions(in the SAML sense) as pretty similar. Could you please rephrase?<br class=""></div></div></blockquote><br class=""></div><div class="">In this context I am using „claim“ for a subject-predicate-object triple like „Alice knows Bob“. An assertion is a verifiable statement by a trusted party, such as a signed XML infoset containing a number of claims.</div><div class=""><br class=""></div><div class="">Forgive me using abstractions and terms outside the usual contents of this list. Let me right this wrong with an example:-)</div><div class=""><br class=""></div><div class="">I will decompose an ordinary server certificate, such as that of <a href="http://www.tiimeworkshop.eu/" class="">www.tiimeworkshop.eu</a> (very much recommended identity event, btw). Removing boilerplate and crypto-scaffolding, you end up with following attributes: </div><div class=""><div class=""><br class=""></div><div class="">Issuer, Validity (from/to), Subject, Public-Key and Certificate Policies</div><div class=""><br class=""></div><div class="">When I structure these attributes into triples I come up with this simplified list:</div><div class=""><br class=""></div><div class=""><div class=""><div class="">1. Issuer /is/ C=US, O=GeoTrust, Inc., CN=RapidSSL CA</div><div class="">2. Certificate /is-valid-between/ 2012-02-06Z00:00:00 and 2017-02-05Z00:00:00</div><div class="">3. Subject /has-CN/ <a href="http://www.tiimeworkshop.eu/" class="">www.tiimeworkshop.eu</a></div><div class="">4. Subject /owns-private-key-of/ Public-Key</div><div class="">5. Public-Key /is-of-type/ RSA 2048</div><div class="">6. Public-Key /has-modulus/ 00:9c:18:c3...</div><div class="">7. Public-Key /has-exponent/ 65537</div><div class="">8. Issuer-CPS /published-at/ <a href="http://www.geotrust.com/resources/cps" class="">http://www.geotrust.com/resources/cps</a></div></div></div><div class=""><br class=""></div><div class="">Now you can label who is authoritative for each claim. The CA is authoritative for all claims except the subject-CN (with a domain-validated certificate it is the domain registrar) and the public key (it is the subject who create, proofs its possession and revokes). Therefore the CA brokers and aggregates trust.</div><div class=""><br class=""></div><div class="">The second example decomposes an EntitiesDescriptor with one SP-EntityDescriptor:</div><div class=""><br class=""></div><div class="">1. entityID /is-member-in/ metadata of XYZ-federation</div><div class=""><div class="">2. entityID /is/ "<a href="https://sp77.example.org/sp.xml" class="">https://sp77.example.org/sp.xml</a>"</div><div class="">3. entity-category /is/ some-attribute-bundle</div><div class="">4. entity /has-role/ SP</div><div class="">5. SP /has-property/ WantAssertionsSigned</div><div class="">6. SP /has-encryption-key/ <x509-cert ...></div><div class="">7. SP /wants-NameIDFormat/ urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</div><div class="">8. SP /has-endpoint/ <md:AssertionConsumerService Binding="..." Location="..." index="0"/></div><div class="">9. SP /is-operated-by/ <md:OrganizationName> ACME </div><div class=""><br class=""></div><div class="">Endpoints, key material and contact persons will be determined by the SP. Who is authoritative for other claims will depend on the federation policy. claim #5 could depend on the SP, or on a mandatory implementation profile. The EntityCategory may depend on the SP’s type of organization or application function. Claim #1 is implicit by being included in an aggregate or MDX published at the federation’s metadata feed.</div></div></div><div class=""><br class=""></div><div class="">Again, as in the CA example, the FO is brokering assertions from other parties. </div><div class=""><br class=""></div><div class="">The graph in the picture below shows the trust dependencies. This is not 1:1 to the previous list, because it is just a quick adoption from a project with a similar problem. I think that you get the idea. </div><div class=""><br class=""></div><div class="">And, of course, having a (gated) public ledger for the triples would allow the generation of metadata and certificates by different parties based on different policies. Trusted brokers would still be needed to simplify metadata consumption by RPs.</div><div class=""><br class=""></div><div class=""><img apple-inline="yes" id="4A439318-4670-49B2-8134-43D6FDECE4D2" height="480" width="640" apple-width="yes" apple-height="yes" src="cid:7F241647-AF2F-4994-962A-F91F4538B5AE" class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">- Rainer</div></div></div><br class=""></body></html>