Holder-of-Key Web Browser SSO Profile

"As part of my work for the National Institute of Informatics and the
UPKI initiative, I've been working on a modified Web Browser SSO profile
for SAML 2.0 that uses holder-of-key confirmation for the client rather
than bearer authentication. The keys for this confirmation are supplied
through TLS using client certificates. This results in a more secure
sign-on process and, particularly, a more secure resulting session at
the SP. There is no need for the SP to do PKI validation or know
anything about the client certificate itself. The specification
supplies an alternative to "Profiles for the OASIS Security Assertion
Markup Language (SAML) V2.0." Excerpt: "The profile allows for transport
and validation of holder-of-key assertions by standard HTTP user agents
with no modification of client software and maximum compatibility with
existing deployments. Most of the flows are as in standard Web Browser
SSO, but an x.509 certificate presented by the user agent supplies a
valid keypair through client TLS authentication for HTTP transactions.
Cryptographic data resulting from TLS authentication is used for
holder-of-key validation of a SAML assertion. This strengthens the
assurance of the resulting authentication context and protects against
credential theft, giving the service provider fresh authentication and
attribute information without requiring it to perform successful
validation of the certificate... A principal uses an HTTP user agent
to either access a web-based resource at a service provider or access
an identity provider such that the service provider and desired resource
are understood or implicit. In either case, the user agent needs to
acquire a SAML assertion from the identity provider. The user agent
makes a request to the identity provider using client TLS authentication.
The X.509 certificate supplied in this transaction is used primarily to
supply a public key that is associated with the principal. The identity
provider authenticates the principal by way of this TLS authentication
or any other method of its choice. The identity provider then produces
a response containing at least an assertion with holder-of-key subject
confirmation and an authentication statement for the user agent to
transport to the service provider. This assertion is presented by the
user agent to the service provider over client TLS authentication to
prove possession of the private key matching the holder-of-key
confirmation in the assertion. The service provider should rely on no
information from the certificate beyond the key; instead, it consumes
the assertion to create a security context. The TLS key may then be
used to persist the security context rather than a cookie or other
application-layer session. To implement this scenario, a profile of
the SAML Authentication Request protocol is used in conjunction with
the HTTP Redirect, HTTP POST and HTTP Artifact bindings. It is assumed
that the user is using an HTTP user agent capable of presenting client
certificates during TLS session establishment, such as a standard web
browser...