[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics
>However, I did not envision that a SOAP body might contain a number of unrelated messages each with its own seperate set of participants. While I concede that >this possibility is not prohibited by the SOAP specification, it seems a poor and >inefficient application design. Is this something you see as likely? DO you have a >usecase in mind? No that's not what I meant. I agree it is good practice for a SOAP message envelope typically contains a single document instance (from application point of view). However, a SOAP message could also have secondary parts (attachments) with possibly little or no important content in the body. This is besides the point. When a SOAP message traverses multiple nodes over some message path, it is possible that certain tokens are produced and/or needed to be attached to a SOAP message at each processing node. These SOAP nodes could be in different security domains. Should we have any relationship and/or grouping of these tokens that may be pertaining to different principals at each node? For Example: [UsernameToken#A added] [AssertionToken#A, BinaryToken#A added [BinaryToken#A removed and UsernameToken#A removed] and AssertionTokenB added] <Node#1>---> SOAP Message #1 ------> <Node#2> -------------> SOAP Message# 2 <Node#N> ----> SOAP Message # N Note that some tokens, e.g. Assertion Token may be carried forward, i.e., be part of the next SOAP message. >> 2) Since additio:nal <tokens> element may be added, wouldn't >> it make sense to be able to optionally encapsulate them together in some >> security header child element? >I don't really understand this question. Do you mean added to the message or added to >the schema? I have only proposed adding a single Tokens element to the schema. Perhaps >this question is simply a restatement of the first one. You show in your example multiple <tokens> elements possibly carried in one SOAP wsse:Security header element. So, although I agree that we need to be able to add a Tokens schema definition. The question is about encapsulating them in some type of container that provides semantics of ordering. >Is "target node" a defined term? Even if I take a guess at what that means, node is defined in section 1.4.1 of: http://www.w3.org/TR/2002/WD-soap12-part1-20020626/ <http://www.w3.org/TR/2002/WD-soap12-part1-20020626/> Target node here basically refers to next node in SOAP messaging path. >Except that the XML tokens are "just inserted" so extending them requires extending >(if possible) other schemas outside of wsse: Furthermore in the case of XML tokens, >they will typically come already signed by some authority. In my proposal, the Purpose >would fall outside of this signature (although within a message signature) because the >same entity might take on different Purposes with respect to different messages, while >being represented by the same token, e.g. a SAML assertion containing an Attribute >Statement. Yes, agreed. thanks, Zahid
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC