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

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

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