[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
impractical.
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
something.
Hal
> -----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