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: [ws-sx] RE: Response to Issue 30 Proposal ( was Proposal for ACTION-2006-03-01-04)


Gudge,

sure, ok with me (I somehow missed that AI).

Regards,
Werner



> -----Ursprüngliche Nachricht-----
> Von: Martin Gudgin [mailto:mgudgin@microsoft.com] 
> Gesendet: Montag, 20. März 2006 19:17
> An: Dittmann, Werner; ws-sx@lists.oasis-open.org
> Betreff: [ws-sx] 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]