Protecting producer registrations

[Michael Freedman <Michael.Freedman@oracle.com>]

Folks,
    During our last concall I asked what if anything is a consumer able 
to do with regards to sharing or migrating a producer registration.  The 
response on the phone was producers shouldn't use registrations contexts 
to establish relationships with a particular consumer.  Rather a 
registration context merely defines/establishes a scoping for portlets. 
 A consumer, in this case is a logical entity, it may be a single 
physical entity or many physical entities.  Producers shouldn't try to 
use any information it received with the registration call to restrict 
which physical consumer it is valid to receive this context from.  It 
was said that the management of that relationship is left up to lower 
levels of the web services [security] protocol stack.

Since that call I have done some thinking about what was said  and don't 
fully understand/disagree with the sentiment.  Basically I don't 
understand how the producer implements the following common use case:

Use Case:
Producer wants to ensure that only authorized consumers can use a 
specific registration.  I.e. a producer wants to make sure that the 
registrationContext it receives is not only valid but came from a 
consumer that was authorized to send it.  The peculiar thing here is 
that set of authorized callers is defined by the consumer and is on a 
per registration scope. In the simple case its just the consumer itself. 
 However, when you consider other real world use cases it can encompass 
a development consumer, a stage consumer, and a production consumer.  At 
a high level I understand how lower layers of the web services stack 
could be used to control the domain of all consumers that can talk to a 
given producer.  However, I don't understand how, if its used 
exclusively, it can be used to control the domain of specific consumers 
for a specific registration.  And more specifically, how this could be 
done without manual administration on the producer to set it up.  Can 
someone write a high-level explanation of how this would work?

Ultimately, what I had expected to be the case was that the register 
call is used to establish both the set or valid consumers and/or the 
validation method for a given registration.  In some[all?] cases the 
validation method could rely on low layer web services [security] 
mechanisms.  i.e. this registrationContext is only valid for a given 
certificate [is this feasible?]. ....  Or are most folks in the camp 
that any producer that wants to isolate / secure consumers to a given 
registration will [always] require manual producer side administration 
and therefore a level of out-of-band registration?  I.e. A valid 
position might be that WSRP doesn't want to deal with this -- any 
producer that wants such function will have to rely on lower layer web 
services and home grown [out-of-band] registration techniques.  

FYI, the use case I am beginning to worry about is the develop, stage, 
production environment portal developers typical design within/deploy 
on.  In such an environment there is a need to migrate/share some 
portlets [those that correspond to base, all user, configurations to the 
stage and production environments.
    -Mike-