>>> >>>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).
Yes, I'm certainly sympathetic to that argument. I agree that for inter-domain delegation, we will need support for this. In that case, Diameter is your friend. However, for intra-domain delegation, I think there's plenty of mileage in using Kerberos delegation semantics (with an unsigned SAML assertion in the PAC) rather than SAML delegation semantics. In this case, we can use RADIUS. >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. Agreed. We should certainly provide a mechanism that supports arbitrarily sized payloads for the reasons you state. However, if a reasonable proportion of use cases can be solved with a simple (if not necessarily comprehensive) RADIUS-based mechanism, we should do that rather than reinvent Diameter. >I'm of course fine with DIAMETER if people are deploying it, or will be >within the next 5 years or so. That's the $64K question. My view is that we should take a pragmatic approach, and provide a simple option that is readily deployable today and which addresses many -- if not all -- use cases, and provide an alternative mechanism to satisfy those other use cases. > 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. That's certainly a possible deployment option although I believe that even in a Diameter-based deployment, there may be a role for proxies and other active intermediaries. However, I think I may have misunderstood the thrust of your question...? 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 Oxford, Didcot, Oxfordshire. OX11 0SG _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
