RE: [wss] Issue: Binary Token & XML Token should be abstract

["Don Flinn" <flinn@alum.mit.edu>]

Chris

Your as bad as I, working Sunday night. :-)

We, the TC, have been very diligent in adding additional important
functionality to the specification.  However, we have not been as diligent
in removing existing functionality that has been or could be duplicated by
new functionality.  I believe that it is important to make a specification
"as simple as possible, but not any simpler". (Quote attributed to Albert
Einstein.)  My goal in this thread is to eliminate functionality that can be
covered by another function/element.

You have brought up a problem, namely an ambiguity in the schema spec.  I'm
not aware of this problem.  Could you give me a pointer?  I have recommended
that an optional EncodingType attribute be added to the STR, which would be
used whenever an embedded token is used.  Isn't this the same solution that
is suggested for the BST in the core spec?

I am not suggesting an <any> attribute for the STR but optional ValueType
and EncodingType attributes to be used when there is an embedded token.

My empirical evidence for the elimination of the Binary and XML tokens is
that only one of all our profiles uses either of these tokens.

Don

-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com]
Sent: Monday, May 19, 2003 1:53 AM
To: Don Flinn; WSS
Subject: RE: [wss] Issue: Binary Token & XML Token should be abstract


Are you suggesting that the STR replace the BST?  You will find that
have an element whose type can be either simple or complex is wrought
with problems.  We tried to do this a while ago and there are problems.
There is an ambiguity in the schema spec which different vendors have
interpreted differently.  Consequently, most tools seem to disagree (or
not work) on this.

I guess I still don't see the motivation.  There is not a lot to be
gained by having one single type for tokens as it ends up having to have
an <any> which eliminates strong type checking.

Also, while there are times when an embedded token in an STR is useful,
I don't see that as the typical case.

Can you explain more about the problem you are trying to solve?

Chris

-----Original Message-----
From: Don Flinn [mailto:flinn@alum.mit.edu]
Sent: Sunday, May 18, 2003 1:30 PM
To: WSS; Chris Kaler
Subject: RE: [wss] Issue: Binary Token & XML Token should be abstract

Chris

Sorry for the delay in getting back to you, my hard disk crashed last
week
and wiped out my life for a week.

First, I agree that using derivation would mean that the derived token
would
need a schema element, xsd:extension base, which is not in the existing
XML
schemas.  We could solve this by another wrapper or requesting
modifications
to existing schemas, both unattractive solutions. On the other hand, of
all
the existing profiles, only the X.509 profile uses either the Binary or
XML
token.

What started me off on this is that I had some difficulty when trying to
explain the functionality of the Binary and XML tokens.  They seemed to
be
not another token but wrappers for all the other tokens whose purpose is
to
carry/make claims.  We already have an element to handle the wrapper
capability, the STR, especially with the addition of the embedded
capability
to the STR.  One could add optional ValueType and EncodingType
attributes to
the STR and it could do the job of the Binary and XML tokens.  I believe
that it is not the best approach to have two elements that can
accomplish
the same task, rather it is better to simplify the schema as much as
possible. (These lessons come from designing libraries.)

Therefore, I once again modify my proposal.  Eliminate the Binary and
XML
tokens and use the STR with optional ValueType and EncodingType
attributes
to handle the task that was originally assigned to the Binary and XML
tokens.  An added benefit is that if any other token types come up in
the
future we can just add new ValueType and EncodingType attribute values
to
the STR.

Don


From: "Chris Kaler" <ckaler@microsoft.com>
To: "Don Flinn" <flinn@alum.mit.edu>,"WSS" <wss@lists.oasis-open.org>
Date: Thu, 8 May 2003 10:39:06 -0700

Wouldn't this mean that each token format would need its own XML
Element?  Since all binary tokens have the same syntax, what is the
advantage over a common element with a value attribute as currently
specified?

Similarly, the two most notable XML token formats exist and are not
derived from anything.  How would you support them in this type system?
The goal was to allow a profile to take existing mechanisms and use them
directly.

Chris

-----Original Message-----
From: Don Flinn [mailto:flinn@alum.mit.edu]
Sent: Wednesday, May 07, 2003 6:32 AM
To: WSS
Subject: [wss] Issue: Binary Token & XML Token should be abstract

I believe that both the Binary Token and the XML Token should be
abstract
types.  This means that they can not be instantiated by themselves but
need
to have a derived element, which, in the present wsse case, would be
defined
in profiles. The existing potential derived profiles are the X.509 and
Kerberos, which would be derived from the Binary Token and the SAML,
XCBF
and XrML tokens, which would be derived from the XML Token.  Additional
profiles may derive from either an abstract type or may be a top level
element.

In my previous mail I suggested that the derived token be in a
substitution
group or a choice.  Subsequent conversations have convinced me that this
would be too restrictive as the intent of the TC was to have an "open"
model. Therefore, I am dropping the later and just proposing that the
Binary
and XML tokens be optional, abstract types.   I believe that the
proposed
inheritance gives structure and clarity to this part of the
specification.

Comments please.

Don

====================
Donald Flinn
Managing Partner
Flint Security
Phone: 781/856-7230
e-mail: flinn@alum.mit.edu
http://dflinn.home.attbi.com