[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: ISSUE:[UC-7-0{1|2}:Enveloping]
> Issue #1 instance > > <envelope> > <body> > <updateSession> > <SAMLAssertions> > </SAMLAssertions> > <Extensions></Extensions> > </updateSession> > <body> > <envelope> > > Issue #2 instance > > <envelope><body> > <sendStuff> > <myStuff></myStuff> > <saml:SAMLAssertions> > </saml:SAMLAssertions> > </sendStuff> > </body></envelope> > > In case #1, I see that the first piece of software that recieves a SAML > request will be a SAML compliant piece of software. It will then have other > parties registered for various pieces of the software. Whereas in case #2, > the first piece of software will be generic and have a pipeline of flow, ie > first step: validate saml components; second step: dispatch to myStuff > handler. > > It seems unclear to me which way an xml processor will operate on the data. > I really think we should have more of an idea of how the software will use > this and flesh out our domain model and interactions before voting on this. > But that might just be the analyst in me. > Hi Dave, I am not sure I fully understand your concerns here. If I send a document of type #1 to be processed by something expecting a document of type #2, then things will fail. But this would be the case even if SAML was not involved - surely the processor has to know how to handle the document? Isn't this just a question of application logic - like having to agree which protocol to use when two parties communicate for anything meaning full to happen? Nigel
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC