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"
<> 

05/23/2005 03:54 PM

To

Andrew Hately/Austin/IBM@IBMUS,
"'Rogers, Tony'" <>

cc

<>

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:]

Sent: Monday, May 23, 2005 15:58

To: Andrew Hately; Luc Clement

Cc: 

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:] 

Sent: Tue 24-May-05 2:30 

To: Luc Clement 

Cc:  

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"
<> 

05/22/2005 10:18 PM

To

Andrew Hately/Austin/IBM@IBMUS

cc

<>

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 

  

Modeling Web services Security in UDDI:
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/12217/uddi-spec-tc-tn-wssecurity-20040328.doc

Modeling HTTP Access Auth in UDDI: http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/11960/uddi-spec-tc-tn-httpauth-20050321.doc
 

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幦ent | 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]