On 11/4/11 10:06 AM, "Cantor, Scott" <[email protected]> wrote:
>On 11/4/11 5:29 AM, "Josh Howlett" <[email protected]> wrote: >> >>Could I ask why? I am satisfied that 4k is plenty for the use-cases that >>I >>see today. Adding support for more will incur significant complexity, >>which feels disproportionate for a corner-case. If people have such a >>corner case, they can use Diameter. > >I'm still doing some research on this (I need to mock up some assertions >using my data and extensions), but my intuition is that I can definitely >not get behind anything with a limit that low. I feel like I should explain that a bit more directly: While most of the >4K use cases I have now are not federated (its usually enrollment data that gets it above the line), my experience is that having two infrastructures (one for intra-, one for inter-) is bad. I also believe support for SAML based delegation is important to gradually move people away from building "client of web service is root" models to get around having decent delegation support. That adds size (as well as signature). I believe it's short shrift to focus on passing small numbers of attributes around, because if you think that's all there is, then that means attributes aren't getting used widely, which means federation's not going anywhere anyway. Authentication alone is not a motivator for the effort involved. Attributes are all that will drive it. I'm of course fine with DIAMETER if people are deploying it, or will be within the next 5 years or so. One question on thatŠwith the intent to move to a model where you connect directly from the acceptor's AAA server to the home server via TLS, does that mean only the two endpoints would need DIAMETER anyway? That's a reasonable compromise. -- Scott _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
