Subject: Re: Party Identity within role-- security and TRP relatedquestions.RE: next conference call - reminder
Dale,
Please see below.
Cheers,
Chris
"Moberg, Dale" wrote:
>
> > -----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!
This is a correct analysis. I like it too;-)
>
> 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?
That was my thinking, yes.
> [ 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.]
Agreed.
> 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?
The PartyId to be used by TR&P would be one of the set of PartyId
elements in the CPP/CPA. PartyDetails is just a link to
some unspecified source of information about the party
(e.g. a directory lookup, a web page, a UDDI business-entity,
etc.)
> 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
Not under the Role, but under the Party element for which the
Role is a child element.
> may not be related to the namespace used in this PartyID.
Hmmm... I'd have to think that one through. I would expect
that the dn of the cert would be the dn of the Party, not
some arbitrary cert belonging to someone else.
> 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.
See above. I think that PartyId should be taken care of
already.
>
> [Another PKI aspect I have witnessed in
> interop tests is the need for variants of certificates
> (same DN to publickey binding, though).
I think that KeyInfo can contain a set of child elements,
each of which can be used to "identify" the owner of the
certificate.
Here's the text of the KeyInfo element from the XMLDSIG spec:
The KeyInfo Element
KeyInfo is an optional element that enables the recipient(s) to obtain the key needed to
validate the
signature. KeyInfo may contain keys, names, certificates and other public key management
information, such as in-band key distribution or key agreement data. This specification
defines a few
simple types but applications may place their own key identification and exchange
semantics within
this element type through the XML-namespace facility. [XML-ns]
If KeyInfo is omitted, the recipient is expected to be able to identify the key based on
application
context information. Multiple declarations within KeyInfo refer to the same key. While
applications may
define and use any mechanism they choose through inclusion of elements from a different
namespace,
compliant versions MUST implement KeyValue (section 4.4.2) and SHOULD implement
RetrievalMethod (section 4.4.3).
The following list summarizes the KeyInfo types defined by this specification; these can
be used within
the RetrievalMethod Type attribute to describe the remote KeyInfo structure as represented
as an
octect stream.
http://www.w3.org/2000/09/xmldsig#X509Data
http://www.w3.org/2000/09/xmldsig#PGPData
http://www.w3.org/2000/09/xmldsig#SPKIData
http://www.w3.org/2000/09/xmldsig#MgmtData
In addition to the types above for which we define structures, we specify one additional
type to
indicate a binary X.509 Certificate
http://www.w3.org/2000/09/xmldsig#rawX509Certificate
> 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...]
See above, I think that this is satisfied by use of
KeyInfo with multiple expressions.
>
> 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.
Hmmm... this is something that we may have to consider.
I would propose that for now we simply have one CPP
per party, even if that "Party" is just a department
in some larger enterprise.
>
> Megacorp might want to put all their collaboration
> contact info into one package for centralizing
> document maintenance (MIS mandated perhaps).
Well, since there's nothing in the spec about *how* one
creates or maintains a CPP, it *could* be that there's
a CPP "template" that is maintained and then transformed,
to add party specifics into multiple CPPs that are effectively
identical to one another except for Party specific info
such as certs, etc.
>
> 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.
Yes, that would have advantages in this regard.
>
> 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
> >
begin:vcard n:Ferris;Christopher tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XML Technology Development adr:;;One Network Drive;Burlington;Ma;01824-0903;USA version:2.1 email;internet:chris.ferris@east.Sun.COM title:Sr. Staff Engineer x-mozilla-cpt:;0 fn:Christopher Ferris end:vcard
Powered by
eList eXpress LLC