Section 3.1.3 - Controller -- Authentication

[jimsch]

version -03

I also have a problem reading the first sentence in this section. It just does not seem to flow well.

I don't understand what the two bullets are trying to say. Are we saying that we do not support the use cases where consumers may request information from a specifically identified provider?

It is also not clear to me, but it might become clearer in the future, how authentication is going to be done. I would assume that for the cases of a consumer not knowing the identity of the provider, it will actually just treat the broker/proxy as if it were the provider. In this case does the consumer not just authenticate itself to the broker and authenticate the broker for itself?

It is not clear to me that the control channel and the data channel are always going to be physically separate. They may be virtually separate but not always. For example, a consumer could talk to a broker, which set ups a channel and on you go. On the other hand, the consumer could just send authentication and authorization data directly to a provider which can validate them and accept the request and process it. This text seems to be overly restrictive in terms of what can be implemented.

[ncamwing]

The intent is to cover both where a consumer requests information from a specific provider, as well as from 'any' provider of the info sought.
Agree that control and data channel does not always imply that they are physically separate (by physically I mean detached from a consumer or a producer)....but where we need to abstract the uplevel of allowing a consumer to get info from 'any' consumer, I think an abstract control function is needed.

[llorenzin]

Nancy to provide suggested new text

[ncamwing]

Jim,
this text was actually moved from section 3.1.3 to now Section 5.1 in v04 and updated to specify the flow. Can you let me know if we need to further address?

[jimsch]

The initial flow is better, but you do not seem to have address any of the rest of the comments.

[ncamwing]

Hi Jim,
In Section 5.1, I will modify as follows:
Authentication: The authentication of Consumers and Providers
independent of the actual information-sharing communication channel.
While authentication between peers (e.g. a Consumer and a Provider)
can be achieved directly through peer to peer authentication (using
TLS for instance), there are use cases where:

*  Consumers may request information independent of knowing the
   identities of the Providers.

*  Providers may want to share the information without prior
   solicitation.

To address the above use cases, the architecture must account for an
abstraction where a Controller may be defined to effect the
authentication of the Consumers and Providers independent of the
actual information-sharing communication channel. Consumers and
Providers that consume or publish information without requiring
knowledge of the Providers and Consumers respectively would function
in a SACM system where the Controller is a distinct entity. As a
distinct SACM component, the Controller would authenticate Providers
and Consumers.

OK? - Nancy