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]

My thinking is that in the real world, security is an afterthought. People
will build systems that construct a business message and sign it. When they
get around to thinking about providing Attribute Assertions with it, they
won't want to change anything they are doing.

For that reason I consider SAML enveloped in a business document to be

Conversly, Enveloping business documents in SAML seems more likely. However,
I don't see why SAML can't just include a hash of the document in the
assertion, protected by the assertion signature.

I admit I have not studied xmldsig's use of these terms, so I may be missing


> -----Original Message-----
> From: Orchard, David [mailto:dorchard@jamcracker.com]
> Sent: Tuesday, March 20, 2001 10:20 PM
> To: security-use@lists.oasis-open.org
> Subject: ISSUE:[UC-7-0{1|2}:Enveloping]
> I think that this issue has not nearly been debated enough to 
> vote upon - I
> accept personal responsibility for my extreme busyness.
> It seems that issue #1 says the design for SAML means it's a 
> set of verbs
> and nouns and it has an <xsd:any> element that allows 
> extensions, and issue
> #2 says that an external vocubalary has <xsd:any> element 
> that allows (SAML)
> extensions.
> I'm really unsure how to vote on these.  I can argue for and against
> different combinations.  The tricky part is that issue #1 
> means that we have
> to define verbs (the outer construct), and issue #2 says that 
> we have to
> define nouns (something that can be embedded inside a 
> different vocabularies
> verbs).  
> 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.
> Dave Orchard
> XML Architect
> Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
> p: 408.864.5118     m: 604.908.8425    f: 408.725.4310
> www.jamcracker.com - Sounds like a job for Jamcracker.
> ------------------------------------------------------------------
> 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