[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
Don, I like the simplicity of this design. And if you considered in your approach adding an optional attribute to indicate a binary transfer of the message, then having a single token type might be very beneficial when secure SOAP messages were used in resource constrained environments. See the attached. A standardized, binary SOAP transfer encoding is being proposed for SOAP messages. If such as this were based on a BER/DER encoding, then the Base64 armoring step for objects like X.509 certificates and XCBF biometric objects might be eliminated. This could serve to reduce overall SOAP message size and eliminate some processing overhead for both the sender and recipient. Phil Don Flinn wrote: >Chris > >I've included some example code below to explain my proposal. Let me say at >this point that since nobody else seems to be interested in this issue, I >will drop it. However, I still feel that the more we can simplify the spec >the less chance of misinterpretation by implementers. > >Using the example for a binary token taken from the core spec: > ><wsse:BinarySecurityToken > xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/06/secext" > wsu:Id="myToken" > ValueType="x:MyType" xmlns:x="http://www.fabrikam123.com/x" > EncodingType="wsse:Base64Binary"> > MIIEZzCCA9CgAwIBAgIQEmtJZc0... ></wsse:BinarySecurityToken> > >Using the SecurityTokenReference for an X.509 binary token: > ><wsse:SecurityTokenReference > xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/06/secext" > wsu:Id="myToken"> > <wsse:Embedded wsu:Id="..." > ValueType="wsse:X509v3" > EncodingType="wsse:Base64Binary"> > MIIEZzCCA9CgAwIBAgIQEmtJZc0... > </wsse:Embedded> ></wsse:SecurityTokenReference> > >An XML token would be carried in the Embedded element with the >ValueType="wsse:XMLSecurityTokenType" and the optional EncodingType not >used. Alternately, the XMLSecurityTokenType could be placed directly in the >security header, as you observed. > >Maybe I have misunderstood the Embedded element, but I thought its purpose >was to carry the actual token. If so, I believe that my example is >semantically correct. > >Don > >-----Original Message----- >From: Chris Kaler [mailto:ckaler@microsoft.com] >Sent: Monday, May 19, 2003 12:22 PM >To: Don Flinn; WSS >Subject: RE: [wss] Issue: Binary Token & XML Token should be abstract > > >There isn't a "pointer" per se to the schema issue. The problem comes >when you want to vary derived elements between simple types and complex >types. We tried this in something called WS-License and ran into >problems with lots of tools. You also likely end up having to go with >"mixed=true" and this isn't a good thing for a number of reasons, strong >typing being one. > >Help me understand your proposal better. If you add an "EncodingType" >to the STR then would you embed the token directly in the STR without a >wrapper? > >I'm not sure I see what the duplicate functionality is. The STR is very >strongly typed (in a semantic way). The STR contains elements to >"reference" a token. One reference mechanism is literal using the >"embedded" element and its type is that it contains a token. Because >the token may be binary, it contains either a direct XML token (of any >kind) or a BST to wrap the binary bits. > >If a token is directly used, it can be placed in the <Security> header >directly either as an XML token or using a BST. This is the preferred >form if it can be used since it limits the amount of parsing necessary. > >Chirs > >-----Original Message----- >From: Don Flinn [mailto:flinn@alum.mit.edu] >Sent: Monday, May 19, 2003 6:54 AM >To: Chris Kaler; WSS >Subject: RE: [wss] Issue: Binary Token & XML Token should be abstract > >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 > > >You may leave a Technical Committee at any time by visiting >http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php > > > >You may leave a Technical Committee at any time by visiting 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]