- From: Fabian Ritzmann <Fabian.Ritzmann@Sun.COM>
- Date: Thu, 01 Mar 2007 12:01:44 +0200
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, ext Maryann Hondo <mhondo@us.ibm.com>, public-ws-policy@w3.org
Hi, I reread the framework and I don't think it is entirely clear in this regard. I believe both points of view could be justified based on the text of the specification. It is very clear that all policy types in a policy expression constitute the policy vocabulary. It is apparently not clear what that means for policy assertions in nested policies. Fabian Yalcinalp, Umit wrote: >> Frederick Hirsch wrote: >> >>> I'm confused. Doesn't >>> >>> >>>> As an example, WS-Security Policy defines sp:HttpToken assertion to >>>> >>>> contain three possible nested elements, sp:HttpBasicAuthentication, >>>> >>>> sp:HttpDigestAuthentication and sp:RequireClientCertificate. When the >>>> >>>> HttpToken is used with an empty nested policy in a policy expression >>>> >>>> by a provider, >>>> >>> this imply that since the assertions are in the vocabulary that none >>> >>> are allowed since not stated, hence the following sentence is wrong? >>> >> None of the nested assertions listed above are in the >> vocabulary of the >> policy that the proposal gives as an example. Only concrete >> occurrences >> of an assertion somewhere in the policy expression are part of that >> policy's vocabulary. >> > > This is interesting. > > > >>>> it will indicate that none of the dependent behaviors namely >>>> authentication or client certificate is required. >>>> >>> it will indicate that none of these are allowed or required? >>> >> In the context of what I said above, I believe the original >> statement is >> correct. And note that the framework does not talk about allowed or >> required, it only states an indication that the assertion is >> not applied. >> >> Fabian >> > > Is there a difference of opinion about what constitutes the vocabulary > of an assertion based on type vs instance ? > > We recommend assertions to have a schema and state dependent behaviors > as expressed as nested assertions. From a definition perspective, it is > not about the "instance" as expressed in a document, it is a about the > "type" of the assertion which lists all the dependent assertions. The > type, hence the Qname in advance declares what it is composed of. > > I have regarded that understanding a type would also imply understanding > all possible nested children (close world model) which is not based on a > specific policy expression instance. > > Am I missing sth? >
Received on Thursday, 1 March 2007 10:02:00 UTC