[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [XML Signature] Issues on Core 19 & Others
I agree with the questions about the meaning/function of multiple assertions. If we can't motivate them with native-SAML use cases, we may want to look seriously at pulling back a bit. If I'm understanding correctly, Phill has been promoting this structure in order to allow for interesting applications built on top of SAML, which is a legitimate data point. I wonder if there isn't a more useful solution: Make the native SAML assertion be "singular" in nature (containing a single statement), and then allow applications to extend the assertion datatype by adding additional statements on the end. In extremely informal DTDish notation, the native assertion type would do this: assertion -> (meta-stuff, (stmt|subjstmt|authnstmt|authzstmt|attstmt)) And the extensions you could create might look like this: my-extended-assertion -> (everything-above, (stmt|subjstmt|authnstmt|authzstmt|attstmt)*) (Sorry, I'm multitasking at the moment and don't trust myself to get an XML Schema version right. I will try to follow up with more specific code.) This would ensure that SAML's semantics for singular assertions are clear, and that while extensions might pick up on native *statement* semantics, they're on their own as regards any "multiples" semantics. Eve At 12:12 PM 10/5/01 -0400, Hal Lockhart wrote: > > The Signature will be an Enveloped Signature as > > per the XML Signature > > specification. There is an issue of support for multiple > > signatures, which I > > plan to research thru. Would appreciate feedback. > >What would the semantics of multiple signatures be? We should decide what we >need to do first and then how to do it. > > > 2. Is there a rationale for *separate* single and > > multiple assertions ? > > Isn't SingleAssertion a MultipleAssertion with one assertion ? Can we > > collapse the SingleAssertion and MultipleAssertion elements > > to one type with > > minOccurs=1. There is no meaning having an assertion without > > an assertion > > type ! > >I agree with the (implied) suggestion. > > > 3. Signing Multiple Assertions: > > Do we have a structure to envelope multiple > > separate assertions ? > >I think it is going to be a lot more convenient for relying parties to sign >each assertion individually. I know there is an performance cost issue, but >it can be helped by reusing assertions. Separate signatures actually help >this, as one assertion can be reused, even if another has to be generated >and signed on demand. For example a static AuthN Assrt and dynamic Attr >Assrt > > > 4. Associating Payload: > > Is there a way for a payload assertion ? i.e. > > make an assertion saying > > that PO is mine. May be this is an attribute assertion the > > attribute being > > the hash of the payload. This almost the same as a detached signature. > >Start by assuming that the payload must be signed by the subject. I guess >this could be debated, but if not then either anybody can forge the payload, >or the function of being an Asserting Party and being a generator of >transactions gets folded into a single trust point. > >I think the result of discussions at the face to face and Bob B's powerpoint >published imediately after was that tying a payload to an assertion can be >done by putting the subject's public key in the Subject Confirmation. > >The point is that whether the Issing party blesses every individual payload >generated by the subject or blesses the subject's key, all it is really >vouching for is that the payload came from the subject, not anything about >the contents of the payload. > >Once this is recognized, it becomes clear that there is no real advantage >for the issuer to bind the assertion to every payload. The disadvantage is >that a new assertion is required for every transaction. > > > There are a few issues here as well: > > > > a) ebXML and RosettaNet has a document > > model and so the object of signing > > would be a MIME part > > b) SOAP Payload is an XML fragment and so > > the object could be an XPath or > > an XPointer (?) > > > > Is Payload signature a binding issue or a "core" issue ? > >Signing the payload itself by the subject is not a SAML requirement at all. > > > > > 5. Of course, the "core" has the SAMLRequest and > > SAMLResponse. Does it make > > sense to add the > > <element ref="ds:Signature" > > minOccurs="0" maxOccurs="1"/> > > to Request (Line 800.1) and Response (Line 973.1) ? > >I remember we discussed that Requests should be authenticatable, especially >in environments, e.g. Shib, where assertion contents depend on who is >asking. I don't recall any argument for signing responses, but there seems >little harm in including the possibility in the schema. I would hope that >the mandatory to implement profiles would not use this signature. > >Hal > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC