Re: [saml-dev] Any work on WSDL for restricted SAML responder?

[Von Welch <welch@mcs.anl.gov>]

True, but as you point out even ripping off the current protocol bits
doesn't solve the problem on the response side since the statements
would still be encapsulated in an Assertion element.

I don't think that is solvable as long as mixing of statements types
is allowed in an Assertion. (If you only wanted to allow one type of
statement this could be solved by extending Assertion for each type of
statement instead of encapsulating statements in an Assertion.)

Von

Scott Cantor writes (15:08 January 15, 2004):
 > > This seems problematic since both of these element are encapsulated 2
 > > or 3 levels below the Request and Response elements, so there is no
 > > easy way to indicate this in the WSDL Message elements. The only way
 > > I can think of would be to define new restricted versions of Request
 > > and Response, which sounds hideous.
 > 
 > This is something I was wondering about, yes.
 > 
 > The basic question is before us as to how to add new protocol exchanges to
 > SAML, and I think we need to be consistent...either the proper thing is to
 > extend/replace the outer elements to carry the payload, making it directly
 > SOAP-visible, or we treat the SAML protocol as the real substrate, and we
 > put the payload inside Request and Response.
 > 
 > That having been said, we would be better served by moving all of the
 > protocol pieces to SOAP, IMHO, and going halfway with it is not all that
 > useful to me. But I don't see that happening, since it would require SOAP to
 > provide things it simply doesn't without inventing headers.
 > 
 > The current design for Query is broken if we think that the "proper" thing
 > is to promote the payload to the outer edge, and should be changed.
 > Alternatively, the answer is that the WSDL can only define the "SAML
 > protocol" and the rest is encapsulated, and defined also by metadata (I
 > support X, Y, Z at this SAML protocol SOAP endpoint).
 > 
 > But the question of restricting statements in a resulting assertion is a
 > different one. We had a poor attempt to do this with RespondWith and it was
 > pretty well detested (by me anyway). As it is, there's not much that I can
 > see to do. The data model is Statements within an Assertion, and without
 > changing that...
 > 
 > -- Scott
 >