[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]