[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Fwd: RE: [wss] New issue: profile version identification]
Ron, Can you put some context around this sequence of notes ? Are you proposing something here ? Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 |---------+----------------------------> | | Ron Monzillo | | | <ronald.monzillo@| | | sun.com> | | | | | | 04/22/2003 11:07 | | | AM | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wss@lists.oasis-open.org | | cc: | | Subject: [Fwd: RE: [wss] New issue: profile version identification] | >----------------------------------------------------------------------------------------------------------------------------------------------| -------- Original Message -------- Subject: RE: [wss] New issue: profile version identification Date: Thu, 19 Dec 2002 15:36:14 -0500 From: Tim Moses <tim.moses@entrust.com> To: "'ronald monzillo'" <ronald.monzillo@Sun.COM> CC: wss@lists.oasis-open.org Ron - This sounds fine to me. It was the versioning of the "profiles", not the "tokens", that motivated the original question. The ProfileVersion attribute that you propose should be of type xs:anyURI, rather than xs:integer, because the "versions" may not emerge from a single configuration management body. I.e. a body other than the WSS TC that wants to write a profile using (say) SAML tokens, should not have to have their profile recognized by the WSS TC. Because of the redundancy that you refer to, if the ProfileVersion attribute were to be attached to the SecurityTokenReference element, does that not mean that the ValueType can remain optional? The necessary information is available from either the ProfileVersion or the ProfileVersion and the ValueType (if it is present). By the way, why do we have an element-name ending in "Type"? Why don't we reserve that ending for the names of type definitions? All the best. Tim. -----Original Message----- From: ronald monzillo [mailto:ronald.monzillo@sun.com] Sent: Tuesday, December 17, 2002 6:42 PM Cc: wss@lists.oasis-open.org Subject: [wss] New issue: profile version identification Jerry did a good job of describing the issue, which I have preserved. Jerry Schwarz wrote: > A. Profiles are specifying "identification", but there isn't any place > to put it. That there is no way to specify what profile or version > the profile a security token (or SecurityTokenReference) is being used. Token specific profiles of wss-security are identified by URN; but as Jerry points out, the specification has not defined how the version of a token specific binding is identified in security tokens, signatures, or security token references, resulting form the use of the profile. I propose that versioning of security tokens is the responsability of the designers of the security token and that the specification of security token version identifiers need not and should not be the responsability of the binding of the token to ws-security. The distintion is less clear when the security token (e.g. username/password) is being defined by ws-security. It would seem that the security token reference forms used in a token specific binding of ws-security should indicate the version of the binding that yielded the reference. Following our earlier discussions I propose that this should be accomplished by addding a mandatory ProfileVersion attribute to the security token reference element. A mandatory ProfileVersion attribute on the STR will not facilitate the versioning of non-STR (e.g. keyName) token references. I propose that such references need not be versioned. I see 2 potential problems with this approach. 1. A manadatory binding/profile version attribute in the STR will implicitly identify the type of the referenced token. This information may introduces a measure of redundancy WRT the ValueType attribute. 2. Because this attribute was proposed as mandatory, its affect would be to require a message sender to implicitly provide ValueType information, that up to now was optional. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]