uddi-spec message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [uddi-spec] Proposal 16: breaking the containment model
- From: Andrew Hately <hately@us.ibm.com>
- To: uddi-spec@lists.oasis-open.org
- Date: Mon, 12 Apr 2004 14:32:56 -0500
The registry cannot add transforms since
the effect of them is applied prior to calculating the signature.
What I have to document is a set of
well known transforms for UDDI and what they mean as far as the signed
content. As you point out, this does not change much in the specification
and is intended to enable different publishers to modify different pieces
of signed data under the existing containment model. The only reason
to document a few well known transforms is that inclusion of a Transform
(beyond enveloped transform and canonicalazation) is something that is
often discouraged, due to the effect that transforms exclude and modify
the orignal data being signed. If the transform and the effect of
the transform is not well known, it should be considered a potential security
hole when verifying the signature.
I agree that there are other attractive
alternatives to the current model which involve breaking containment, but
I believe we need to document several approaches to access control, since
there is a high implementation cost (associated with changing the data
model. Of larger concern than the implementation cost is the stability
of UDDI as a technology. This should force us to examine all proposed
solutions to see if there is an alternative that fits within the some constraints
imposed by the UDDI V3 specification and data model.
I'm not sure if it's reflected in the
minutes, but there are several proposals where we should continue to develop
at least two solutions, one which uses only the existing structures and
containment and one which introduces new structures and a new containment
model. We can weigh the benefits/costs of each approach when all
of the solution alternatives are developed.
Regards,
Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies
Lotus Notes: Andrew Hately/Austin/IBM@IBMUS
Internet: hately@us.ibm.com
(512) 838-2866, t/l 678-2866
"Daniel Feygin"
<feygin@unitspace.com>
04/11/2004 11:07 AM
|
To
| "'Rogers, Tony'"
<Tony.Rogers@ca.com>, <uddi-spec@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [uddi-spec] Proposal
16: breaking the containment model |
|
I was reading too much into it.
It is obvious that if we split entity ownership across multiple publishers,
then each publisher would sign just the part of the entity that (s)he owns.
But I do not see why this singular
issue cannot be accommodated within the existing containment model. All
we have to do is specify that signature is computed based upon entity content
excluding contained entities (services, bindings and potentially contacts).
Contained entities need to have their own signatures produced by
their respective owners. These signatures would validate the contained
entities' inclusion in their containing entity because their content includes
the key of the containing entity. Whether a publisher can submit
a contained entity for inclusion in some other entity should be governed
by the containing entity's ACL.
As far as spec goes, it should
say "all children of the element being signed are included in the
generation of the signature unless they have their own signature element,"
so all children endowed with signature are automatically excluded. This
is different from current spec text, which states that "all children
of the element being signed are included in the generation of the signature
unless first excluded by application of a transform." This appears
to presume that all of the entity's contained entities are owned by one
publisher.
The registry itself can add the
required transforms (that filter out contained keyed entities) to signatures
that do not have such transforms.
I still believe that the publisherAssertion
containment-free approach is a better alternative, because it supports
greater flexibility and has better controls at the same time.
Daniel
From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Sunday, April 11, 2004 1:59 AM
To: Daniel Feygin; uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Proposal 16: breaking the containment model
That phrase "signature transforms
to allow signature compartmentalization" just
means writing transforms so that the signature in a business just signs
the business, and not any of the contained objects, and the same for a
service. That way we can suppress a binding or a service without disrupting
the signature on the service or business which contains it. This was an
important reason for breaking containment.
-----Original Message-----
From: Daniel Feygin [mailto:feygin@unitspace.com]
Sent: Sat 10-Apr-04 3:11
To: uddi-spec@lists.oasis-open.org
Cc:
Subject: [uddi-spec] Proposal 16: breaking the containment model
I have read the FTF minutes' discussion of proposal 16
and have these
thoughts on the matter.
First, I need to admit that I don't understand what is meant by "signature
transforms to allow signature compartmentalization" and how that would
work.
It sounds like something that has the potential to make signatures work
within the framework currently proposed for requirement 16. However
I see
another option of how the concept of containment might be transformed in
V.Next to support ACL granularity and limit their impact on invalidation
of
signatures.
My thoughts on this center around extending the use of publisherAssertions
to provide the mechanism to link all types of keyed entities to each other.
This would allow us to do away with containment for all keyed entities
and
thereby make it easier to satisfy these requirements:
- filtering out search results inaccessible in a particular query;
- completely separating maintenance of different entities;
- supporting service projections (although they can now be deprecated if
we
choose to allow multi-homed services/bindings);
- both publishers control the "inclusion";
- signing the relationship can be supported by adding two signatures ("from"
and "to" publishers') to the publisherAssertion structure
This solution would entail publishing canonical tModels to represent the
relationships between businesses, services, bindings and contacts. It
may
also provide a way to redesign isOwnedBy and isReplacedBy type of solutions
that currently rely on keyedReferences in lieu of publisherAssertion support
of uddiKey (vs. businessKey).
This would simplify the rather complicated visibility rules discussed in
the
minutes. With this proposal, it seems that they can be collapsed
to just
one: if the user does not have access to one of the entities linked by
the
publisherAssertion, then that publisherAssertion is invisible to the user.
Of course, this is in addition to V3 publisherAssertion visibility
constraints. I don't really see a plausible way to reconcile ACLs
with
keyedReferences (to hide keyedReferences with invisible tModelKeys), since
-
unlike publisherAssertions - they are embedded inside an entity and their
exclusion would inevitably break the signature. Perhaps we can add
a rule
that by signing an entity, the publisher makes the whole entity invisible
to
all inquirers who have at least one part of the entity hidden from them.
This is less of an issue if publisherAssertion linking is used, because
references to serviceKeys and bindingKeys become external to the content
of
the entity.
The nice thing about this approach is that appears to simplify
implementation by reusing existing schema providing a uniform design for
all
links across entities. Requirement 27 would also be solved by this.
Daniel
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]