In Moonshot, we have explicitly seperated the problem of (1) applying
federated identity in a non-web SSO protocol, from (2) the problem of
deciding how these actors establish trust in each other.

We believe that we can solve both problems using essentially the same
approach. However, by keeping these as separate concerns we can avoid
requiring that non-web applications must use a particular trust
establishment method. Many people will want to keep using their existing
entity trust establishment methods, and it is important that we continue
to make that possible.

I've spent some time analysing the implementation implications -- for
the non-web SSO part only -- for the Shibboleth IdP and SP with Sam and
Scott. We think that the implications for the Shibboleth SP are fairly
modest (much of the work will be done by the EAP GSS library and
mod-auth-kerb) and trivial or non-existent for the Shibboleth IdP.

That's the good news.

It gets more complicated when you attempt the same analysis for the
'entity trust establishment' problem. What we're trying to do in this
case, in summary, is the following:

1. Enabling a metadata consumer (IdP or SP) to verify that a SAML
metadata <EntityDescriptor> is an accurate description of a 'target
entity' (IdP or SP), according to a third party whom it trusts to make
this claim.

2. Establishing keys for the metadata consumer and target entity that
they can use to secure their communications.

Normally, keys are named or represented explicitly in the entity's
metadata; whereas Moonshot proposes deriving keys dynamically.
Therefore, the Moonshot approach for the 'entity trust establishment'
problem is significantly more intrusive than the 'non-web SSO' case.

What I'm currently trying to understand is whether we can decompose the
'entity trust establishment' problem into two smaller and more
digestible problems, such that we can usefully address them
sequentially.

In Moonshot, we propose that the metadata consumer obtains an
<EntityDescriptor> for the target entity (the "how" is intentionally
out-of-scope, as it is orthogonal to the trust calculus) and establishes
trust in this descriptor by attempting to validate its own credential
against a special-purpose endpoint given in this <EntityDescriptor>
using the EAP GSS mechanism. A successful authentication results in the
metadata consumer obtaining a token, through the GSS-API, whose value
contains a hash of the <EntityDescriptor>. If the metadata consumer can
match this hash against its own independent calculation of the hash, it
can infer that the descriptor is valid and the metadata is 'accepted'.

Because this is GSS, the metadata consumer and target entity (described
by the descriptor that has just been validated) now share a GSS security
context whose Base key can be used to derive keys for the SAML crypto
operations.

What I believe is that the first half of this (metadata acceptance) will
be significantly easier to implement in existing SAML software than the
second part (application of the derived keys for SAML crypto). I'm not a
SAML implementer, so I would be interested to hear the opinions of those
of you who are!

Note that the end-point that the metadata consumer applies its
credentials against does not need to be co-located at the target entity.
It can be anywhere, providing that a trust path exists between the this
endpoint and the metadata consumer's own trust authority. It could, for
example, be an endpoint operated by the TTP. Therefore this endpoint is
not necessarily a SAML implementation consideration.

All the SAML implementation needs to do is (1) somehow obtain the entity
metadata for the target entity (if it hasn't already 'accepted' it and
cached this state), (2) play its credential against the endpoint using
HTTP/Negotiate/EAP-GSS (3) extract the token that gives the hash using
the GSS-API and (4) compare this against a locally computed hash. 

If this is the case, when it comes to implementation I suggest that
there is a strong argument for shooting /initially/ for the first part
of this, and using conventional (meaning SAML Metadata Inter-operability
Profile) keying. This means that SAML entities need both an EAP
credential and a public/private key pair; however, the latter can /also/
be used as an EAP credential and so it should be possible for entities
to hold a single credential (even if means the use of a public/private
keypair).

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG