[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss] ACTION([Ron]: Propose what to do about SAML 2.0 assertionIDs.
Tony, I am resending with the agreed to change, because when I re-read your comments, it occured to me that you may have been responding to the msg I sent that detailed feedback I recieved from the SS TC. The resolution accepted by the WSS TC was version neutral. Ron *** x Tue Nov 16 09:40:09 2004 --- y Tue Nov 16 09:41:07 2004 *************** *** 3,14 **** the wsu:Id attribute so that recipients need not understand the full schema of the message for processing of the security elements. That is, they need only "know" that the wsu:Id attribute represents a schema type of ID which is used to reference elements. However, because some ! key schemas used by this specification don't allow attribute extensibility (namely XML Signature ! and XML Encryption), this specification also allows use of their local ID attributes in addition to the wsu:Id attribute. As a consequence, when trying to locate an element referenced in a signature, the following attributes are considered: o Local ID attributes on XML Signature elements o Local ID attributes on XML Encryption elements o Global wsu:Id attributes (described below) on elements In addition, when signing a part of an envelope such as the body, it is RECOMMENDED that an ID reference is used instead of a more general transformation, especially XPath [XPATH]. This is --- 3,15 ---- the wsu:Id attribute so that recipients need not understand the full schema of the message for processing of the security elements. That is, they need only "know" that the wsu:Id attribute represents a schema type of ID which is used to reference elements. However, because some ! key schemas used by this specification don't allow attribute extensibility (namely XML Signature, ! XML Encryption, and SAML Assertions), this specification also allows use of their local ID attributes in addition to the wsu:Id attribute. As a consequence, when trying to locate an element referenced in a signature, the following attributes are considered: o Local ID attributes on XML Signature elements o Local ID attributes on XML Encryption elements + o Local ID attributes on SAML Assertions o Global wsu:Id attributes (described below) on elements In addition, when signing a part of an envelope such as the body, it is RECOMMENDED that an ID reference is used instead of a more general transformation, especially XPath [XPATH]. This is Ron Monzillo wrote: > Tony, > > The addition to core does not profile of the use of SAML 2.0 > assertions with WSS. > It sustains the use of direct local STR's with all versions of SAML > (current and > future), as is consistent with the objectives of the core (i.e to be > extensible to diverse > security tokens types). > > This isssue was resolved in the TC teleconf of Nov 4, at which time the > text was reviewed and accepted for inclusion. > > Ron > > Anthony Nadalin wrote: > >> Ron, >> >> 2.0 is not final yet and I don't believe that anyone has tested the >> SAML Token Profile with SAML 2.0 implementation, so pending the >> completion of these 2 item I'm not for adding this to core yet. May >> want to talk about this tomorrow. >> >> Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 >> Ron Monzillo <Ronald.Monzillo@Sun.COM> >> >> >> Ron Monzillo <Ronald.Monzillo@Sun.COM> >> >> 11/02/2004 08:29 AM >> >> >> >> To >> >> "'wss@lists.oasis-open.org'" <wss@lists.oasis-open.org> >> >> cc >> >> >> Subject >> >> [wss] ACTION([Ron]: Propose what to do about SAML 2.0 assertion IDs. >> >> >> >> >> wrt issue 334, I brought this up in the SS TC treleconf. >> >> I asked if the SS TC would consider reverting the name (ID) of saml 2.0 >> assertion identifiers back to the name (AssertionID) used for 1.0 >> and 1.1 assertion identifiers. >> >> I learned that the attributes are in different name spaces, and as >> such even if they had the same relative name, they would be different >> attributes. >> >> Thus our poposed resolution to issue 334, that is, adding AssertionID >> to the WSS core as a direct ID reference mechanism, would not be >> sufficient >> to sustain local direct references to SAML 2.0 Assertions. >> >> To sustain local direct references to SAML 2.0 Assertions, we would >> have to >> permit the use of the saml v2.0 ID attribute in local direct references. >> >> I recommend that we add both attributes to the WSS core as >> permitted/supported >> attributes in local direct references. >> >> Ron >> >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php. >> >> >> > > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]