One design previously discussed is: if you want others to invoke your action but not read the source, simply keep the action private but expose a REST API.

aka web action? :)

In my specific scenario, the action in question is intended to be a feed action.

It cannot be a web action because the value of __OW_API_KEY will be that of the action owner, not the caller as is currently needed. While this could be resolved by passing the correct key as a parameter to the action, this increases the changes needed in the CLI to make wsk trigger create -f <feed> continue to work, and really special cases feed actions that are web actions, likely requiring a new flag like --web for the user to know about and use in order to get the CLI to behave correctly.

As @rabbah alludes to above, having an API in front of the non-shared action (whether automatically with a web action or otherwise) makes the situation even worse. While we could special case it in the CLI, REST API users would have no clue about the REST call and the correct dance steps they need to perform in order to create a new trigger from this feed.

While this could be resolved by passing the correct key as a parameter to the action, this increases the changes needed in the CLI to make wsk trigger create -f continue to work

doesn't the feed today receive the key of the caller already?
https://github.com/openwhisk/openwhisk/blob/master/tools/cli/go-whisk-cli/commands/trigger.go#L155

So while the __OW_API_KEY is the owner's key - the action already receives - by the feed lifecycle contract - the user (caller's) key.

Interesting. I was not aware of that, or stopped being aware of it when we switched over to use the __OW_API_KEY environment variable in our feed actions. 🤔

so then problem solved? activate only can be solved by web actions, you get the user key, you can validate it, and apply business logic... we would mandate that all feed lifecycle managements are just APIs calls with a fixed schema?

Yes I think that may work. The other key info we need is the namespace (to construct the trigger URL) but that already gets passed along as part of the triggerName parameter. What bothers me though is that at some point in the past we specifically changed the feed action code to stop using the authKey parameter in favor of using __OW_API_KEY and stopped parsing the namespace out of the triggerName parameter in favor of using __OW_NAMESPACE. I'm a little concerned about why we did that, and will undoing it take us a step backward.

https://github.com/openwhisk/openwhisk-package-kafka/pull/103/files

In any case, I'll start implementing it with a web action and see if I can't make it fly. We will still need to teach the CLI (and all other clients really) how to invoke feed actions that are web actions...

Update: We starting using __OW_API_KEY to stop using whisk. getAuthKey()

The reason we could not use the namespace that was passed in with the triggername was because it would often pass in _ for the namespace which was not unique. We used the __OW_NAMESPACE to get the real resolved namespace for _. We definitely still need the resolved namespace name. We use the namespace as part of the id when storing the cloudant and kafka trigggers in cloudant. It needs to be unique.

You can call the openwhisk API for namespace/list with the key and get back the namespace. This is for example a way for the feed API to validate an authorization token.

Update: We starting using __OW_API_KEY to stop using whisk. getAuthKey()

This was just wrong :) should have used the value from the trigger life cycle event. Sorry if I missed that change. But to @jasonpet's point, the outlined solution in this comment will address _.

To teach the CLI to call a feed action I suggest we work through what it means to say that the life cycle handler is always a HTTP/REST call. It should be cleaner, intuitively.

I want to continue discussion from #3015.

Above mentioned 2 features are exactly what I also want.

But in my scenario, user will use my action via shared package.
In my company, user can navigate all shared packages from UI and get easily what they want.

If I expose my action as web action or just normal action, I should manually share my url and auth key. It is not feasible in my case.

So I want to take advantage of sharing feature in package along with hiding my codes or parameters which contain secrets.

If desired approach is to have more fine-grained entitlement, I hope it is also applied in shared package.

This was implemented by @bkemburu #4935.