RE: [wss] Issue 196 QNames: Proposal to use URIs for Typeidentifiers

[Peter Dapkus <pdapkus@bea.com>]

It's worth pointing out that our TC is going against a fairly well
established precedent of using URIs instead of QNames.  XML Signauture,
XML Encryption, SAML, and XACML all use URIs in the places this spec
uses QNames.   For example, XML Signature uses URIs for identifying all
the signature, digest, c14n, and transform algorithms.

It seems like a mistake to abandon the established precedent in favor of
something that has the problems David, Rich and others have identified.
Maybe we should bring ourselves into line with other standards, esp
given the close relationship between those standards and this one.

-Pete


On Mon, 2003-12-15 at 14:49, David Orchard wrote:
> I thought I would provide a bit of motivation for why I posted a solution to
> issue 196.  I provide my understanding of the problem.  Please let me know
> if I am incorrect in this being a problem or if there are other problems.
> 
> The problem occurs when the tokentype attribute is extended with a third
> party token type and then the token type is canonicalized.  In particular,
> the namespace name of the 3rd party token might not be in scope at the
> tokentype attribute, and so a canonicalizer will not preserve the namespace
> name.  A c14n implementation can be "told" the extra namespace names to
> include, but this implies that the c14n implementation is coupled to the
> token type implementation.  This may not be the case in some security
> implementations, such as using multiple technology providers.  Using URIs
> removes this dependency and also removes any potential ambiguity around
> canonicalizing the token type.
> 
> cheers,
> Dave
> 
> > -----Original Message-----
> > From: David Orchard [mailto:dorchard@bea.com]
> > Sent: Monday, December 15, 2003 8:07 AM
> > To: wss@lists.oasis-open.org
> > Subject: [wss] Issue 196 QNames: Proposal to use URIs for Type
> > identifiers
> >
> >
> > This proposes to use URIs instead of QNames for valuetype and
> > encoding type
> > identifiers.  Rather than provide a mapping to URIs,
> > potentially at a later
> > date, the use of URIs should result in cleaner and more
> > secure environments.
> >
> > The first part of this proposal is that valueTypeEnum should
> > be of type URI.
> > The WSSE specification defines 5 values for this URI,
> > replacing the current
> > QNames.  The URI for identifying these types could be constructed in a
> > variety of ways.
> >
> > The following shows identifiers using the fragment identifier
> > syntax.  For
> > the valuetypeenums, this looks like (pending the actual URI
> > assigned for the
> > wsse namespace):
> > http://www.oasis-open.org/wsseuri#X509v3
> > http://www.oasis-open.org/wsseuri#Kerberosv5TGT
> > http://www.oasis-open.org/wsseuri#5ST
> > http://www.oasis-open.org/wsseuri#PKCS7
> > http://www.oasis-open.org/wsseuri#PKIPath
> >
> > And for encoding types this is:
> > http://www.oasis-open.org/wsseuri#Base64Binary
> > http://www.oasis-open/org/wsseuri#HexBinary
> >
> > This might also require a simple change to the schema to add
> > these IDs to
> > the schema.
> >
> > This could easily be a "/" separator instead of "#" as well.
> > The # would
> > definitely be a good way to go if there was a wsse media
> > type.  But there
> > isn't, so "/" could also be acceptable.
> >
> > Cheers,
> > Dave
> >
> >
> > 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.
-- 
Peter Dapkus <pdapkus@bea.com>