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


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

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

Subject: RE: ISSUE:[UC-7-0{1|2}:Enveloping]

In general terms, I would characterize this issue 
as scoping or providing a framework for the
bindings work. Typically, XML processors are organized
around some kind of flexible packaging or protocol
framework: MIME, SOAP, ebXML, home-grown, etc. All of the more
mature frameworks provide "hooks" for additional stuff
like transactional state, security, headers of various
sorts. Legacy and home-grown protocols may not have these
flexibilities "built in"; I assume this is the case where
CR-7-01 would be of interest.

The idea of developing a SAML + business payload packaging framework
(essentially [CR-7-01:Enveloping] sounds pretty daunting to me.
It may be a "univeral" solution but one for which I guess we 
will not have sufficient bandwidth. MIME provides a compromise
in this space, as it is an existing "universal" packaging
framework and a SAML MIME binding may provide a general
enough setup.

- prateek

>>-----Original Message-----
>>From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
>>Sent: Thursday, March 22, 2001 1:32 PM
>>To: 'Orchard, David'; security-use@lists.oasis-open.org
>>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
>>> parties registered for various pieces of the software.  
>>Whereas in case
>>> the first piece of software will be generic and have a 
>>pipeline of flow,
>>> 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
>>> 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
>>> 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?
>>To unsubscribe from this elist send a message with the single word
>>"unsubscribe" in the body to: 

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

Powered by eList eXpress LLC