Sam,

> At least in the IETF I've held a
> very strong position over the years that you never want to force
> someone to deploy multiple security infrastructures.  

Rationalising our customers' security infrastructures is the motivation for this project. So, I'm in complete agreement with this.

However, it has been a few weeks or months since we postulated the requirement for the alternative mechanism. Consequently, I think it might be useful to re-consider the alternative mechanism in light of the progress that we have made since.

1. I think we originally believed that MTP was going to be less tractable than the alternative mechanism. However I now believe that we have a really good understanding of MTP, particularly with respect to implementation; whereas the alternative mechanism is less well understood.

2. Even assuming that MTP takes longer to implement than we currently expect, for the purposes of the proof-of-concept it is not unreasonable to assume that participants deploy parallel federated AAA and SAML infrastructures. So as a transitory step, for the purposes of demonstration and testing non-web SSO, this doesn't seem unreasonable. Of course, it is not reasonable to require parallel infrastructures for a wider-scale deployment, and so we would need good confidence in our ability to deliver MTP if we were to pursue an MTP-only strategy.

3. Let's assume that we are successful in implementing the alternative mechanism as a transitory step. From a service perspective, transition measures often have a habit of becoming annoyingly sticky (e.g., NAT, TKIP, etc). In this particular scenario, there may be inertia caused by the network effect of the legacy technology that your peers are using. So, if we choose to pursue the alternative mechanism while recognising that MTP is superior, I think we want to be confident that we have a persuasive exit strategy.

4. While it may not be substantially different, we know that implementing both is going to cost more than just implementing MTP.

> I think this one may have a simple answer. I think that the metadata
> authority is in a position to know the. client's entity Id and assert
> it in the AAA response.

I think that's a good solution.

> At least that's true in the one-hop case.  I have
> not considered how this works in a transitive case, especially when
> Radsec KMP gets involved.

In the case of a KMP established RadSec connection, the attribute asserting the entity ID is going directly from the AAA server (metadata authority) to the target entity.

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