[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
>>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
>>
>>------------------------------------------------------------------
>>To unsubscribe from this elist send a message with the single word
>>"unsubscribe" in the body to:
>>security-use-request@lists.oasis-open.org
>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC