On 9/23/11 5:06 PM, "Josh Howlett" <[email protected]> wrote: > >I think we ultimately need a profile specific solution for Abfab's >purposes, and a generic binding that can be applied to other domains. The >problem is that its all being shoehorned into single document. Here's a >proposal: > >1. RADIUS SAML attribute (Abfab): specifies encapsulation of SAML messages >within RADIUS messages, per 01. >2. RADIUS SAML binding (OASIS): generic application of (1) for the puspose >of a SAML binding >3. Abfab profile (Abfab): application of RADIUS SAML binding within Abfab >architecture (covers issues such as authentication and attribute request) > >I had assumed that (3) would end up as part of the architecture document, >but that's now non-normative so perhaps we need a new document...
Well, you definitely need (3) in some normative document, and it's really the most important piece in SAML terms. I can see having (1) on its own for reuse. (2) doesn't necessarily have to be done on its own right out of the gate; it could be combined with (3) as part of the profile, and if there's interest in reuse, then a new binding could be done to factor it out. At an implementation level, this isn't the kind of binding you really get leverage from anyway. The HTTP and SOAP bindings are all playing in a common framework and you implement them using obvious reusable widgets so that you can plug them in. I don't really see that here because the transport is very specialized (at least to those of us not steeped in this stuff). Unless you have in mind that other bindings over the same transport are on the horizon. -- Scott _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
