OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss-comment] recursive Security Token References


So, if we edited 903-904 as follows (removing things in {} and adding
things in []), would the new words be sufficiently unambiguous?

"This optional attribute specifies an abstract URI for {where to find} a
security token. If a fragment is specified, then it indicates the local
ID of the [security] token being referenced. [The URI MUST identify a
security token.  The URI MUST NOT identify a wsse:SecurityTokenReference
element, a wsse:Embedded element, a wsse:Reference element, or a
wsse:KeyIdentifier element.]"

&Thomas.

] -----Original Message-----
] From: Conor P. Cahill [mailto:concahill@aol.com]
] Sent: Wednesday, August 31, 2005 3:16 PM
] To: DeMartini, Thomas
] Cc: Tech Rams; wss-comment@lists.oasis-open.org;
wss@lists.oasis-open.org
] Subject: RE: [wss-comment] recursive Security Token References
] 
] 
] 
] DeMartini, Thomas wrote on 8/31/2005, 5:52 PM:
] 
]  > Please see lines 903-904 of
]  >
http://www.oasis-open.org/committees/download.php/13397/wss-v1.1-spec-
] pr
]  > -SOAPMessageSecurity-01.pdf.  In light of those lines, do you still
]  > think we need to strengthen the language?  (Note that the language
on
]  > those lines clarifies that we are pointing to a *token*, not *token
]  > reference*.)
] 
] Yes.  I certainly understand how you could read and interpret this as
] being as restrictive as you say.  I also understand and see how others
] who weren't involved in the generation of this spec could read and
] interpret this more loosely (looking at an STR with an embedded token
] as a "logical" security token or, perhaps, reading more into the
phrase
] "where to find" in the first sentence).
] 
] Others would just say that since it's a reference it could refer to
] a reference too and since that isn't explictly prohibited, the would
] assume (and yes, I know what happens when one ASSuMEs) it was allowed.
] 
] All of that aside, I think we have a good use case for using the
] STR outside of the scope of the WS-Security header and it would be
] a good thing if we could reuse the same type.
] 
] Conor
] 
] 
] 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]