On 7/19/10 5:55 PM, Sam Hartman wrote:

So if you allow me to take a few steps back, I am losing track of the 
problem we try to solve here... pardon the ignorance.

What we are talking about is:

- 2 'SAML peers' and
- 2 'AAA-peers'

and you need to establish trust between the SAML peers (and between the 
user and the IdP) and/or between the AAA-peers (and presumably some kind 
of channel binding between  SAML and AAA, right?

Is it fair to assume that either there is a pre-existing (possibly 
transitive) trust between the SAML peers or between the AAA-peers? Or in 
other words, there must be either some sort of metadata manager for SAML 
or a way for AAA-peers to verify that the other side belongs to the 
'roaming consortium' for lack of a better word?

What am I missing something completely?

Klaas

>>>>>> "Josh" == Josh Howlett<[log in to unmask]>  writes:
>
>      Josh>  Aren't these responsibilities of the MTP metadata authority?
>      >>
>      >>  Ah, yes.  Let's put it a different way: to run MTP you need an
>      >>  MTP authority.
>      >>
>      >>  I think that's an unreasonable requirement
>
>      Josh>  Ok, I believe it's a reasonable requirement.
>
>      Josh>  For the metadata authority, it only implies an EAP server plus
>      Josh>  some registration processes. I think we have a good
>      Josh>  implementation story for that.
>
> It's the registration processes I object to mostly.  Someone trusted by
> all the participants has to collect information and validate it that we
> would not need if we were using ASM or RADIUS for attributes.
> The set of information an MTP authority needs is not really the same  as
> the AAA core.
>
> Also, in addition to what's listed above, you have all the policy that
> is needed to decide what metadata to accept as well as implementation of
> this policy in code.
>
> Also, either the MTP authority is run by the AAA core or it isn't.  If
> it is, my business case argument applies: I believe there's not sufficient
> justification to set up MTP simply for authorization.
> If it is not run by the AAA core then the cost is much higher: you need
> to register with the AAA core and with the MTP authority.
> What happens if not everyone trusts the given authority?
>
>
>
>
>      Josh>  For the metadata consumer and target entity, it implies MTP
>      Josh>  client and server implementations respectively. As of last
>      Josh>  week I think we also now have a good story for the MTP server
>      Josh>  implementation. The story for the MTP client implementation is
>      Josh>  not quite as concrete yet, but I think it is looking perfectly
>      Josh>  tractable.
>
> Hmm. I thought we had good MTP client implementation stories as well
> after last week.  Having to run the MTP server just to get RADIUS-style
> authorization seems kind of expensive as a requirement to me, although
> if it were the only obstacle it wouldn't bother me much.