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

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

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


Subject: RE: [uddi-spec] The need to adopt a policy framework - concerns over thecurrent approach taken on modeling security/auth



Luc,

Here are my initial comments that we can discuss further tommorow.

The attached policy proposal only addresses UDDI Version 3 and does not include the V2 discussion from PolicyAttachment:  "A different approach has to be taken to associate a Policy Expression with a bindingTemplate, since bindingTemplates do not contain a categoryBag in UDDI Version 2. Therefore, the bindingTemplate's tModelInstanceInfo and instanceParms MUST be used as follows..."

Was this an intentional ommision?

One thing to discuss tommorow is wether policies that affec t"on the wire" transmission should be modeled with the V2 approach to allow the technical fingerprint in UDDI to be a complete representation of the technical components required to build a successful "on the wire" message.  (Section 1 of WS-Policy discusses policy assertions with and without "wire" manifestations).

I believe the approach of using keyedReference elements for all other policies as described in the existing policy attachment specification is probably the appropriate direction.

For the two technical note drafts everything is related to security policies that would affect the "wire" format of the message, I believe the current model can be adapted for reusable policy and that the current modeling resulting in a complete technical fingerprint has value from a tooling perspective in that the technical binding can be built by following tModel references as opposed to a mixed metaphor of keyedReferences and tModel references.  The downside, of course, is different policy to UDDI mappings for different policy domains.

So my initial reaction is that we're close with the exception of where to put policy references that impact "on the wire" representation of messages and on the topic of V2 compatibility at the binding template level.

We also still have to resolve the issue around what should constitute a composable, reusable policy for these specific domains of security policies and that was the area that will take the most effort as far as getting broad agreement.

Regards,

Regards,
Andrew Hately
IBM Software Group, Emerging Technologies




"Luc Clement" <luc.clement@systinet.com>

05/23/2005 03:54 PM

To
Andrew Hately/Austin/IBM@IBMUS, "'Rogers, Tony'" <Tony.Rogers@ca.com>
cc
<uddi-spec@lists.oasis-open.org>
Subject
RE: [uddi-spec] The need to adopt a policy framework - concerns over the current approach taken on modeling security/auth





Andrew: please consider the attached – a document I put together hurriedly so please excuse the flaws. I disagree that your mapping is consistent with PolicyAttachment – albeit it is close. Let’s review your approach and compare it with the attached. I think we will find divergence in the approach.
 
Can we discuss this tomorrow during the call?
 
Luc
 



From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent:
Monday, May 23, 2005 15:58
To:
Andrew Hately; Luc Clement
Cc:
uddi-spec@lists.oasis-open.org
Subject:
RE: [uddi-spec] The need to adopt a policy framework - concerns over the current approach taken on modeling security/auth

 
We definitely need a liaison with the WS Policy WG. Is anyone in the TC also in WS Policy?
 
Tony
-----Original Message-----
From:
Andrew Hately [mailto:hately@us.ibm.com]
Sent:
Tue 24-May-05 2:30
To:
Luc Clement
Cc:
uddi-spec@lists.oasis-open.org
Subject:
Re: [uddi-spec] The need to adopt a policy framework - concerns over the current approach taken on modeling security/auth


>>

I’m very concerned about making any recommendations that should (MUST) be expressed using policy by any other means. I think we should take a step back; finally take that bold move and adopt WS-Policy; and recast these two TNs using WS-Policy/PolicyAttachment.

<<



Regardless of the framework, one of the challenges is that these Technical Notes are proposing composable/reusable policy pieces.  I believe they are compatible with WS-Policy as they exist today and we would just need to reference WS-Policy files and we should probably do so.  If you are proposing something deeper in terms of policy framework integration such as changing the concept of UDDI searching to be based on something deeper than tModel concept searches, we should discuss this tommorow.


In my opinion the challenge is not picking the framework or language, it is getting these reviewed by people who can articulate if we've got the write reusable policy pieces that would be composable.


Should we form a liasion with the W3C policy working group to move this forward?


Regards,



Andrew Hately
IBM Software Group, Emerging Technologies


"Luc Clement" <luc.clement@systinet.com>

05/22/2005 10:18 PM


To
Andrew Hately/Austin/IBM@IBMUS
cc
<uddi-spec@lists.oasis-open.org>
Subject
[uddi-spec] The need to adopt a policy framework - concerns over the current approach taken on modeling security/auth

 


   





Andrew,

 
Something hadn’t been sitting well with me with the approaches you’ve taken on these two TNs
 

 
The problem stems from the fact that we’ve yet to adopt a policy framework for registry and the approach you’ve taken though not strictly incorrect is only delaying what in my opinion is the inevitable – the adoption of a policy framework for UDDI.

 
Had we one, we wouldn’t take the approach you’ve taken which as far as I’m concerned is the only reasonable one for you at this point within the current framework – or lack-thereof. That said, it isn’t reasonable for us to delay adopting a policy framework – dare I say WS-PolicyAttachment and WS-Policy.

 
I’m very concerned about making any recommendations that should (MUST) be expressed using policy by any other means. I think we should take a step back; finally take that bold move and adopt WS-Policy; and recast these two TNs using WS-Policy/PolicyAttachment.

 
Luc
 
Luc Clément
| Senior Program Manager | Systinet Corporation |

One van de Graaff Drive Burlington, MA 01803

Phone +1 781.362.1330 | Mobile +1 978.793.2162 | Fax +1 781.362.1400 |

 [attachment "Proposed framework for policy in UDDI.doc" deleted by Andrew Hately/Austin/IBM]


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