Sam wrote:
>     >> The acceptor has the credential shared with the TAS (trust
>     >> authority near server for the archive).  The artifact is being
>     >> issued by the TAC (trust authority near client).  We could have
>     >> the acceptor start conversing directly with TAC and use EAP-GSS
>     >> to bootstrap a credential.
> 
>     Josh> Right. This is what I was proposing with "recursive
>     Josh> discovery". TAS recurses through the trust graph until it
>     Josh> finds TAC, and they converse directly. Policy can 
> be enforced
>     Josh> at any point along the trust graph so that if 
> someone doesn't
>     Josh> want these entities talking, they can enforce that.
> 
> I thought you were proposing that TAS obtain a credential with TAC.

That's where I started from. But I think that it is cleanest to fold TAS
into S, and then use recursive discovery to walk the trust graph from
the start. For example, if necessary S can walk to a local TA (for name
authorisation) before exploring the trust graph outside of the local
trust domain to find TAC.

> What we need for artifact resolution is for S to obtain a 
> credential with TAC.
> So, S needs to be an X server, AAA client, artifact 
> resolution client and  key management client.

Correct.

I think the AAA client and SAML artifact resolver are implemented in the
GSS library (and, of course, any downstream trust authorities that TAC
walks to).

I think the key management client is somehow invoked or implemented by
the TA. We need to figure out an approach to the key management client
that will cause minimum pain to application developers and deployers
(think shared web hosting environments, etc).

>     Josh> I'm not concerned about the authenticity of the 
> artifact; let
>     Josh> us assume that we have satisfied that. I'm 
> concerned about the
>     Josh> authenticity of the SAML message that we obtain when we
>     Josh> resolve the artifact. If the acceptor does not authenticate
>     Josh> the IdP, it could be obtaining an assertion from an 
> issuer who
>     Josh> is not who they claim to be.
> 
> Ah!  My terminology failure.  Can we include a hash of the 
> SAML message in the artifact or along side the artifact to 
> get authenticity of the SAML message?

Yes, that would work fine.

I think I still have a preference for the AAA approach for reasons
pertaining to SAML aesthetics, but I'm struggling to articulate these,
and your hashed-artifact approach is certainly cheaper. I'll sleep on it
:-)

Jumping back to where we started - the SAML RADIUS Binding - I think we
can call the actual mechanism used to establish trust for artifact
resolution out-of-scope for this spec. That's what the SAML
specification does for the HTTP Artifact binding. We can then profile it
in one of the higher-level specs.

best regards, 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