[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Response to Issue 30 Proposal ( was Proposal for ACTION-2006-03-01-04)
Werner, It sounds like this issue is converging on being addressed by the action item Prateek and I took on the last call; AI-2005-03-15-01 - Gudge and Prateek to draft a new section "Guidance on creating New Token Assertions and Token Assertion Extensibility" for review by the TC" Would you agree? If so, I think we should take your proposal below as input into the new section. Gudge > -----Original Message----- > From: Dittmann, Werner [mailto:werner.dittmann@siemens.com] > Sent: 20 March 2006 08:00 > To: Martin Gudgin; ws-sx@lists.oasis-open.org > Subject: AW: Response to Issue 30 Proposal ( was Proposal for > ACTION-2006-03-01-04) > > Gudge, > > of course you are rigthe that every Policy is extensible > with QNames. > > The idea behind the "extension bucket" was from a > WSP parser's point of view: such a parser usually looks at > the WSP domain specific QNames. To instruct the parser also > to accept other namespaces I had the idea of introducing > this "extension bucket" that gives the information which > namespaces are acceptable. This information could also be > given by a configuration file - doing it inside the Policy > was just an additional way to do it. > > If it is more convenient to do it without the "extension > bucket" (I like that expression :-) ) then we could state > something like that: > > <proposal> > A wsp:Policy allows arbitrary elements, that is, it is > extensible. Such arbitrary elements extend the assertion > (property?) set defined by WSP. The extension elements MUST > (SHALL?) follow the same requirements given in WS Policy > framework regarding strongly typed assertions (refer to > chapter 3.1 of WS Policy Framework spcification). > > The semantic of extension elements are out of scope of the WSP > specification and shall be agreed before usage of the Policy. > > The following example shows a X509Token assertion that contains > an extension element that further qualifies the assertion: > > ... > <sp:X509Token > > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securit > ypolicy/IncludeToken/Never" > > <wsp:Policy> > <ext:someElement xmlns:ext="uri:SomeNamespace" someAttr="..." /> > <sp:RequireIssuerSerialReference /> > </wsp:Policy> > </sp:X509Token> > ... > > </proposal> > > specification of that > > itself . > > > -----Ursprüngliche Nachricht----- > > Von: Martin Gudgin [mailto:mgudgin@microsoft.com] > > Gesendet: Sonntag, 19. März 2006 23:38 > > An: ws-sx@lists.oasis-open.org; Dittmann, Werner > > Betreff: Response to Issue 30 Proposal ( was Proposal for > > ACTION-2006-03-01-04) > > > > Werner, > > > > My responses are inline below. > > > > Regards > > > > Gudge > > > > > > > All, > > > > > > here a proposal how to extend assertions. > > > > > > This AI is related to issue 30. > > > > > > > > > <Proposal> > > > > > > The mechanism to extend a policies (token assertions) uses the > > > following notation: > > > > > > <sp:Extensions sp:ExtensionNamespace="xs:anyURI" > > > > <wsp:Policy> > > > <any namespace=##other ...> + > > > </wsp:Policy> > > > </sp:Extensions> * > > > > > > The sp:Extension assertion can occur more than once in a (policy) > > token > > > assertion to define several extensions with different > > namespaces. The > > > sp:ExtensionNamespace attribute defines the namespace of the new > > > assertions. > > > > > > The namespace of assertions inside the sp:Extensions assertion > > > MUST match the namespace given in the sp:ExtensionNamespace > > attribute. > > > > > > The semantic of the extension assertions and their > > attributes is out > > > of scope for the WSP specifications. > > > > Just to be sure I understand what your intent is here; the > > above defines > > an element that allows nested policy expressions, but those policy > > expression can only be drawn from the namespace defined in the > > sp:ExtensionNamespace attribute. Is that correct? > > > > > > > > Simple example: > > > > > > <sp:Extensions sp:Namespace="uri:SomeNamespace"> > > > <wsp:Policy> > > > <ext:Extension_1 xmlns:ext="uri:SomeNamespace" attr="value" /> > > > <ext:Extension_2 /> > > > </wsp:Policy> > > > </sp:Extensions> > > > > > > </Proposal> > > > > > > > > > Some internal notes/rationale behind the proposal: > > > > > > The above proposal requires to define the sp:Extensions > assertion in > > > the WSP specification. > > > > > > The above notation uses the XML schema notation "any" to > define that > > > any well-formed XML is permitted. The namespace "##other" > > defines that > > > any namespace except the target namespace can be used here. > > > > > > Using an extension mechanism in this way is compatible with > > WS-Policy > > > and behaves correct when using normalize, merge, and intersect > > > policy operations. > > > > I don't disagree with the above assertion. However, I note that > > wsp:Policy itself allows arbitrary elements, that is, it is > > extensible. > > I'm not sure I understand why we need a bucket for > 'extension elements > > from namespace X'. Why can't a processor just look for elements > > qualified by the required namespace. Same matching semantics, same > > merging etc. but no need for an sp:Extensions element. > > > > > > > > IMHO the WS-SX TC shall reserve an own extension namespace > > to be able > > > to define own proposed extensions, e.g. to define the setup > > of tokens > > > such as UsernameToken or SAML tokens. > > > > Why wouldn't any and all assertions defined by the spec be > in the same > > namespace? > > > > > > > > > > A more complex example: > > > > > > <wsp:Policy > > xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";; > > > > > >xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";; > > > > > >xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-20040 > 1-wss-wsse > > curity-utility-1.0.xsd"> > > > <sp:SignedEndorsingSupportingTokens> > > > <wsp:Policy> > > > <sp:X509Token > > > > > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securit > > ypolicy/In > > cludeToken/Never" > > > > <wsp:Policy> > > > <sp:Extensions sp:Namespace="uri:SomeNamespace"> > > > <wsp:Policy> > > > <ext:Usage xmlns:ext="uri:SomeNamespace" > > Type="manager" /> > > > </wsp:Policy> > > > </sp:Extensions> > > > <sp:RequireIssuerSerialReference /> > > > </wsp:Policy> > > > </sp:X509Token> > > > <sp:AlgorithmSuite> > > > <wsp:Policy> > > > <sp:Basic256 /> > > > </wsp:Policy> > > > </sp:AlgorithmSuite> > > > <sp:SignedParts> > > > <sp:Header Name="Header3" Namespace="uri:namespace_3" /> > > > </sp:SignedParts> > > > </wsp:Policy> > > > </sp:SignedEndorsingSupportingTokens> > > > </wsp:Policy> > > > > Assuming I bought the requirement for token usage > assertions (which I > > still don't), I'd re-write the above as; > > > > <wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; > > > > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";; > > > > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401 > > -wss-wssec > > urity-utility-1.0.xsd"> > > <sp:SignedEndorsingSupportingTokens> > > <wsp:Policy> > > <sp:X509Token > > sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securit > > ypolicy/In > > cludeToken/Never" > > > <wsp:Policy> > > <ext:Usage xmlns:ext="uri:SomeNamespace" Type="manager" /> > > <sp:RequireIssuerSerialReference /> > > </wsp:Policy> > > </sp:X509Token> > > <sp:AlgorithmSuite> > > <wsp:Policy> > > <sp:Basic256 /> > > </wsp:Policy> > > </sp:AlgorithmSuite> > > <sp:SignedParts> > > <sp:Header Name="Header3" Namespace="uri:namespace_3" /> > > </sp:SignedParts> > > </wsp:Policy> > > </sp:SignedEndorsingSupportingTokens> > > </wsp:Policy> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]