[OpenID] [Shib-Users] SAML 1.0 Browser POST Profile configuration

[Peter Williams]

One fun thing to do is to put a hash(s) of hash chains in the cn naming fields of the https endpoints serving [saml2] metadata. See
http://www.fwsudia.com/bhtpap2c.pdf for background. Metadata validity, entitlements validity, attribute scope effectiveness/pertinence ...are all obvious applications.

One of the core things that folks failed to patent (since it was a variant of prior art in DNS resolvers) was to either (1) put (reverse) hash chain roots (H365,H365',H365'',...) in the DNS domain-name components borne in the CN field of a cert issued by a public CA and distributed by the https endpoint, or (2) let a specifically wildcard cn cert issued by a CA enable a virtual web server to offer resolver services where hash chain values are released as additional domain components in the HOST fields of HTTP1.1 responses, or 30x redirects, or...

Eg 1. In the EE cert, get the CA to issue an https cert where the cn=hash365.hash365'.hash365''.rapattoni.com (authenticating 3  "root" hash chains), much as folks did in the world of DNS reverse lookups, years ago.

Eg 2. In the EE cert, get the CA to issue an https cert where the cn= *.rapattoni.com. GET https://<registeredhash>.resolver.Rapattoni.com will simply 301 redirect to https://hash365.hash365'.hash365''.rapattoni.com (or https://hash365''''.hash365'''''.hash365''''''.rapattoni.com for some subset of roots for the requestor's subnet, or clientcert, or SAML assertion, or ...).

You can play all sorts of core IP-free games using https redirects within the certified wildcard namespace as a validity protocol for [metadata] documents served from https endpoints. Do GET https://<metadatahash>.rapattoni.com you can get a redirect to https://<hashsig>.<metadatahashchaindailyval>.rapattoni.com on day n, where hashsig = hash(<metadatahash> + <metadatahashchaindailyval>)

I've already applied these general ideas to openid discovery of cached XRDS-format metadata for openids and delegate openids (since openid discovery formalizes the role of 30x redirects). It also applies to the recovery of Openid-RP XRDS files by openID-OPs before releasing an assertion (a resolution process that is highly analogous to the issue in question: SAML-IDP recovers SAML2 metadata directly from SAML2-SP entity, prior to releasing an assertion (or an attribute, entitlement).

> There's no value in pointing the IdP directly at the SP for metadata.
> There's no basis to trust it. That's the whole reason we have
> federations.
> This is doubly true if the SP isn't signing the metadata it's
> returning.
>
> -- Scott
>
>