Michael
I'm not sure this is true. If it is adhering to the token profile then it also knows saml:AssertionId so should not require schema processing.
Isn't this right?
regards, Frederick
Frederick Hirsch
Nokia
> -----Original Message-----
> From: ext Michael McIntosh [mailto:]
> Sent: Friday, June 25, 2004 10:53 AM
> To: Hirsch Frederick (Nokia-TP/Boston)
> Cc: Anthony Nadalin; ;
>
> Subject: RE: [wss] Comments on SAML Token Profile
>
>
> <> wrote on 06/25/2004 10:17:25 AM:
>
> > Why cannot reference saml:AssertionId if specified in profile? Same
> xsd:Id type as
> > wsu:ID, also "well known" to profile. Same properties as
> wsu:Id. Why a
> problem?
>
> Because WSS implementation knows wsu:Id is of type xsd:Id.
> In order for it to know saml:AssertionID (or any other token defined
> attribute) is of type xsd:Id, requires schema processing.
>
> >
> > regards, Frederick
> >
> > Frederick Hirsch
> > Nokia
> >
> >
> >
> > > -----Original Message-----
> > > From: ext Anthony Nadalin [mailto:]
> > > Sent: Thursday, June 24, 2004 7:01 PM
> > > To: Maneesh Sahu; Michael McIntosh
> > > Cc: wss
> > > Subject: Re: [wss] Comments on SAML Token Profile
> > >
> > >
> > > Also pointed out is to use KeyIdentifier
> > >
> > > -
> > > Anthony Nadalin
> > > Sent from my BlackBerry Handheld.
> > >
> > >
> > > ----- Original Message -----
> > > From: "Maneesh Sahu" []
> > > Sent: 06/24/2004 04:20 PM
> > > To: Michael McIntosh/Watson/IBM@IBMUS
> > > Cc: <>
> > > Subject: RE: [wss] Comments on SAML Token Profile
> > >
> > > Hi Michael,
> > >
> > > Adding a wsu:Id to the SecurityToken - the SAML Assertion
> in this case
> > > would cause it to violate the SAML schema. Is this permissible?
> > >
> > > --ms
> > >
> > > -----Original Message-----
> > > From: Michael McIntosh [mailto:]
> > > Sent: Thursday, June 24, 2004 3:04 PM
> > > To: Ron Monzillo
> > > Cc: Anthony Nadalin;
> > > Subject: Re: [wss] Comments on SAML Token Profile
> > >
> > > Ron Monzillo <> wrote on 06/24/2004
> > > 12:01:08 PM:
> > >
> > > >
> > > >
> > > > Anthony Nadalin wrote:
> > > >
> > > > > We ran into some inconsistencies while participating in
> > > the recent
> > > > > SAML interop. The WSS core specification describes a "Direct
> > > > > Reference" mechanism to be used with STRs. A Reference
> > > element with
> > > a
> > > > > URI attribute is used. When the referenced token is
> located within
> > > the
> > >
> > > > > Security header, the URI contains a shorthand XPointer
> > > reference to
> > > > > the token. In order for this to work, the token element
> > > must contain
> > >
> > > > > an attribute of type ID. WSS defines the wsu:Id attribute
> > > with type
> > > ID
> > >
> > > > > for naming the reference. Direct references within the message
> > > should
> > > > > not require token specific methods so we suggest the following
> > > actions
> > >
> > > > > be taken:
> > > > >
> > > > > 1) Errata to the WSS core to make it clear the tokens
> > > must have an
> > > > > attribute named wsu:Id.
> > > > > 2) Change to the SAML Token Profile to use an wsu:Id
> attribute or
> > > use
> > > > > a wsse:KeyIdentifier
> > > > >
> > > > These changes are not a good idea.
> > >
> > > It is a good idea, otherwise the dereferencing mechanism
> would require
> > > XML
> > > schema processing to enable it to identify which
> attributes were ID
> > > type.
> > >
> > > Please see my response to Rich Levinson.
> > >
> > > >
> > > > The wsu:id attribute was defined for use as a
> convenience where new
> > > shema
> > > > elements are being defined, or with elements which support
> > > attribute
> > > > extensibility
> > > > and which do not already include an id attribute.
> > > >
> > > > The only constraint on using an STR Direct Reference with a
> > > fragment
> > > > containing
> > > > an id value is that the thing being referenced must have an
> > > attribute
> > > of
> > >
> > > > type id.
> > > >
> > > > In SAML V1.1 the AssertionID attribute so qualifies, that is:
> > > >
> > > > <attribute name="AssertionID" type="ID" use="required"/>
> > >
> > > I do not understand the aversion to adding the wrapper
> > > element. It seems
> > >
> > > to me that it makes it easier for services to support the
> > > profile. Using
> > >
> > > the known ID type of wsu:Id facilitates extensibility of
> platforms to
> > > enable new token types. Using token specific mechanisms for
> > > references
> > > potentially requires modifying the core WSS dereferencing
> > > processing for
> > >
> > > every new token type.
> > >
> > > >
> > > > Ron
> > > >
> > > > PS: I also concurr with Rich Levinson
> > > >
> > > > > In particular, the ValueType attribute (lines 702-708)
> > > appears to be
> > >
> > > > > intended
> > > > > to provide token-specific processing rules to be applied in
> > > > > conjunction with
> > > > > the URI attribute. In the case of SAML 1.1
> assertions, the SAML
> > > ValueType
> > > > > indicates that the saml:AssertionID should be treated as
> > > an XML ID
> > > type
> > > > > attribute.
> > > >
> > > > >
> > > > > Anthony Nadalin | work 512.838.0085 | cell 512.289.4122
> > > > >
> > > >
> > > >
> > > > 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.
> > >
> > >
> > >
> > >
> > > 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.
> > >
> > >
> >
> > 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.
> >
>
>
