Re: [security-services] wrt SAML artifact definition

["Eve L. Maler" <Eve.Maler@Sun.COM>]

I guess I see your point.  I just want to make sure that profiles remain 
the "unit of interoperability" and that we don't monkey with their 
backwards compatibility too much in the name of "elegance."

	Eve

Scott Cantor wrote:

>>Yikes, this is a big change from how we've been using it, though it does 
>>hew more closely to the WS-I-ish meaning.  Actually, our profiles seem 
>>most like "protocols" to me!  But I imagine we should stay far away from 
>>this.
> 
> 
> They currently are a mix of protocol, binding, and profile, thus the yuck
> factor. Separating the protocol out is not terribly hard, but there will be
> some work to isolate the binding and profile aspects of the 1.x profiles.
> 
> But I don't think it's that bad. I believe that the sending of messages over
> the various mechanisms (SOAP, form POST, URL, artifact->SOAP) is separable
> from the "SSO profile", which describes the allowed message content during
> SSO depending on the binding used.
> 
> Most of that content will be binding-independent, IMHO, and the "profiles"
> as they currently stand might be pretty minimal, standing more as examples
> of using the protocol in a particular use case context. I'd really rather
> see the key normative aspects moved to protocol and binding text.
> 
> To illustrate this, consider the form POST "profile", which is just a
> protocol response message delivered alongside a TARGET parameter. That
> parameter belongs in the Response inside RelayState. As such, the profile
> amounts to saying put the protocol message in a base-64 encoded form element
> called "SAMLResponse" and that's a binding, not a profile.
> 
> -- Scott
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com