[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Comments on SAML Token Profile
My interpretation is that it should not require schema processing if the
guidelines
on lines 418-425 of the core spec are followed to change
the configuration of the parser (as was referenced in earlier email):
"Conformant processors that do not support dynamic XML Schema or DTDs
discovery and
processing are strongly encouraged to integrate this attribute definition
into their
parsers. That is, to treat this attribute information item as if its PSVI
has a
[type definition] which {target namespace} is
"http://www.w3.org/2001/XMLSchema";
and which {name} is "Id." Doing so allows the processor to inherently know
how to
process the attribute without having to locate and process the associated
schema.
Specifically, implementations MAY support the value of the wsu:Id as the
valid
identifier for use as an XPointer [XPointer] shorthand pointer for
interoperability with XML Signature references."
Any implementation that has done the above to support the wsu namespace
with local name "Id" should find it straight forward to also then support
the saml namespace with local name "AssertionID".
Rich Levinson
Netegrity
-----Original Message-----
From: Michael McIntosh [mailto:mikemci@us.ibm.com]
Sent: Friday, June 25, 2004 10:53 AM
To: Frederick.Hirsch@nokia.com
Cc: Anthony Nadalin; maneesh@westbridgetech.com; wss@lists.oasis-open.org
Subject: RE: [wss] Comments on SAML Token Profile
<Frederick.Hirsch@nokia.com> 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:drsecure@us.ibm.com]
> > 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" [maneesh@westbridgetech.com]
> > Sent: 06/24/2004 04:20 PM
> > To: Michael McIntosh/Watson/IBM@IBMUS
> > Cc: <wss@lists.oasis-open.org>
> > 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:mikemci@us.ibm.com]
> > Sent: Thursday, June 24, 2004 3:04 PM
> > To: Ron Monzillo
> > Cc: Anthony Nadalin; wss@lists.oasis-open.org
> > Subject: Re: [wss] Comments on SAML Token Profile
> >
> > Ron Monzillo <Ronald.Monzillo@Sun.COM> 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
.
>
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]