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: "Daniel Feygin" <feygin@unitspace.com>
- To: "'Andrew Hately'" <hately@us.ibm.com>,<uddi-spec@lists.oasis-open.org>
- Date: Wed, 14 Apr 2004 20:39:34 +0400
Please see inline.
The registry cannot add transforms since
the effect of them is applied prior to calculating the
signature.
DF:
Well, then that will not work :)
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.
DF:
If we keep the containment model unchanged for V.Next, then the
registry can be held accountable for making sure any signature applied
to an entity conforms to a known set of transforms, which should be based on the
granularity of our ACL expressions. In fact, there should probably be
exactly one valid set of transforms per each entity type. That combined
transform should filter out all contained entities that have their own signature
element. If a signature does not have the required transform, then the
signed entity should be rejected by the registry as non-conformant to signature
rules.
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.
DF:
Very good points. Granted, for each design change (rather
than extension) to the V3 spec we should seek to balance its worth against the
discontinuity we create.
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.
DF:
I didn't see the containment-free proposal posted by or
assigned to anyone. If there is interest in pursuing that, then I
can volunteer to document one option. Is proposal 16 the right
place for it?
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]