Party Identity within role-- security and TRP related questions.R E:next conference call - reminder

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: Tuesday, January 23, 2001 9:46 PM
> To: ebxml-tp@lists.ebxml.org
> Subject: Re: next conference call - reminder
> 
> 
> I'd like to submit this revised version of my Role proposal for
> consideration in tomorrow's call. I have attempted to clear up
> some of the confusion regarding the semantic meaning of the Override
> element by tweaking its description a bit.

Ok, I think I read the former document too fast and it should
have been clear to me. Sorry. But let me check: 

The "multiplicity" of associations of a BP under a Role
with DeliveryChannels is now captured within the 
multiplicity of ServiceBinding elements where
the collaborationIDs are identical. For these ServiceBindings,
the distinct channelIDs point to the alternative DeliveryChannels.
I like that so I hope I understood it this time!

Here are some questions based on this reading but directed
to other related issues:

1. Is the presence of the CertID at this location to capture
the "authorizing role" information? So the DN of this certificate
is the identity to be checked on the payload, for example?
[ Separate CertIDs might be used by the messaging service
to sign the ebxml header for example, and yet another
cert might be involved in client side SSL authentication.]
Also, speaking of identity, I had hoped that whatever
PartyID will be used in the ebXML header could be 
stored in this location; is that information in PartyDetails?
But I thought that was now just an xlink? Anyway the ebXML
header From/To is to draw values from some identifier name space
for businesses or from URIs or whatever. Will we have this
information accessible under the role element? The DN may or
may not be related to the namespace used in this PartyID.
I think both the what-is-needed-by-runtime and the what-is-needed
to-set-up-interoperable-implementation criteria favor adding
this element just as much as the CertID, and in the same location.

[Another PKI aspect I have witnessed in
interop tests is the need for variants of certificates
(same DN to publickey binding, though).
Different collaborators were unable 
to understand or even
deal with certain extended attributes 
(not even criical ones),
or with different character sets 
used for parts of the DN,
and so on. Since some people
already had one flavor of certificate,
a new one readable by new collaborators
was issued in addition to the original.
So CertID could need more than one...]



2. I have forgotten what, if anything, had been said
about multiple parties in a CPP. I could see 
multiple DUNS+4 identities bundled up in one
CPP. 

Megacorp might want to put all their collaboration
contact info into one package for centralizing
document maintenance (MIS mandated perhaps).

Also, if we were trying to retrieve from a registry
just one selling locus from within Megacorp,
once the registry had
been searched by industry to find Megacorp, 
then a single URL would point to the needed
CPP. No more drill down needed.

I realize that there are also many considerations
favoring a finer grainsize for CPPs, and to keep
each simple. But if we limit the expressive power,
we effectively prevent the big bundle approach
by design and force a multitude of smaller
documents. I do not know which of these approaches
is going to be better in practice so I tend to
favor expressive power able to handle bundles.

3.



> I've also updated the list of sources for the Role name to 
> align it with the BPM based on some discussions I had with Karsten
> today.
> 
> This version has change tracking enabled from the previous version
> I sent out so that the changes are easily identified.
> 
> Cheers,
> 
> Chris
>