OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] wrt SAML artifact definition


> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]