RE: Comments on ebXML RegRep Security-002.doc (jdm)

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

I am not convinced that the security object needs to be distributed,
specifically based on the existing requirements.  

Fact: A registry instance (A) can be a RegistryClient to another registry
instance (B).

Scenarios:

-If a request to instance A involves an ExternalObject in registry B, then
the registry instance A establishes a trusted connection to the other
registry B (via A's own certificate, with default read-only) .  

-If the request on A is to update the ExternalObject in registry B (which I
have serious problem with), then the requestor also needs to be
authenticated and authorized on B.  That poses a TRP question, or a
pass-through mechanism to pass the certificate and request, which implies
the distributed security object so stated.

One key point is that we DO NOT replicate CONTENT in this distributed
approach, which is an RA implementation option (load-balancing, etc.), NOT
that specified by ebXML.  If there was a requirement for replicated content,
then this is an REAL issue.  But its not a requirement.  

Therefore, an ExternalObject should not be a copy of one that is local to
any given registry instance. (probably needs to be in the RIM document).

Scott

> Line 167-168:  If role based access control and access control 
> policies are 
> not visible outside of the registry, and as lines 172-178 imply, then why 
> bother to specify them at all.  This specification seems to say in Phase I

> "Anyone authentic user can publish, anyone can view."  How does 
> this lack of 
> visibility of access control polices outside of the registry 
> affect the use 
> or architecture of "distributed registries?"   How is security 
> "distributed?" 
<ks> 
Phase 1 motto is "Any known entity can publish and anyone can view". I am 
not pleased at all, but no choice. 
So far we have no notion of a distributed registries. But if they are 
distributed, then the security objects would also be distributed. So no 
problems. If an object is distributed, we will need to replicate the related

security objects as well. It of course raises the sync problem - which the 
distributed registry paradigm has to solve. Definitely not in Release 1 (as 
I know of) 
</ks> 


===