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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


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/securitypolicy/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]