RE: [security-services] Metadata IOP & the front-channel bindings

["Scott Cantor" <cantor.2@osu.edu>]

Josh Howlett wrote on 2009-10-05:
> I'm curious how the IOP addresses the confidentiality and integrity
> requirement of the front-channel bindings (c.f. "Security and Privacy
> Considerations") from the 'metadata alone'.

I believe that the front-channel bindings take some care to distinguish the
bindings' requirements for confidentiality/integrity, and the front channel
itself. Specifically, Redirect and POST say:

"The presence of the user agent intermediary means that the requester and
responder cannot rely on the transport layer for end-end authentication,
integrity and confidentiality."

The artifact binding text is a bit more muddled, I admit.

Anyway, this was the justification for speaking broadly in the spec without
intending to pull in the browser-facing stuff.

It could be clearer where it mentions TLS, which of course is referring to
entity to entity communication only.

> I suspect that I'm interpreting the quoted extract too broadly (ie.
> this spec is scoped to metadata consumers/publishers, and trust
> interactions between other actors are out-of-scope), but a
> clarification would be very welcome!

The scope is not metadata consumer/publisher. That's termed "exchange" in
this document, I believe, and is explicitly out of scope. But it also isn't
meant to constrain a front-channel TLS certificate (if there even is one),
because such a credential would not be expressed in the metadata (at least
not in its capacity on the front-channel).

Consider the questionable practice of implementing message-level encryption
of data to a service by hitting its TLS endpoint and (mis)using its
certificate as an encryption key. If one were to implement a fat client that
was interested in using an SP's (or IdP's) metadata to derive an encryption
key to use, that key would be there explicitly as an encryption key, not in
its role as a TLS server certificate.

So even if the key would be in the metadata, it wouldn't be there because of
the front channel.

-- Scott