TSAS — 2.3.1.1, 2.3.1.2, 2.3.1.3 and 2.3.1.4

2.3.1.1, 2.3.1.2, 2.3.1.3 and 2.3.1.4

This is a big issue related to the operations in the above mentioned
sections.

list_available_services returns a list of services containing a sequence

of ServiceInfo that is serviceId, UserServiceName and
ServicePropertyList.
The serviceId and the ServicePropertyList are used as input for the
operation select_service, which returns a token. The service_token than
is used as
input for start_session operation( TINA like) or Sign_service_agreement
(Parlay).

The service token is used by both operations to identify the service and

the service properties. I don't see any reason for having a
select_service
operation, which returns nothing different than the select_service
operation. Can we
therefor delete the operation select_service?

In order to keep more alignment between Parlay and Tsas I would propose
to move the start_session operation to a seperate new segment. There is
no need
to have parlay specific and Tsas specific operation in the Core segment,
which
should be the common segment for both. Start_session uses
ApplicationInfo as
input.
Additional operation get_service_info is needed for the
service/application environemnt
before the service user interface can be launched. Additionally, the
user needs the operation set_user_ctxt (3.4.2.1), move this operation
before start_session. The seperate start segment is than for
"one-stop-shopping" environments. ApplicationInfo is a struct containing
some
fixed parameters and some properties. Can we move the fixed parameters
to the property list?

The sign_service_agreement operation seems to be very similar to the
subscrition operation create_service_contract at the service contract
management
inteface. the only difference is that ith the subscription operation you
can
subscribe for more than one service. In additon to that there is no
explicit demand
for a signature, this is dependent on the implementationa and the
provider, if that is
necessary. There is always the argument of non-repudiation for this
operation,
which I never understood. As far as my knowlegde is, non-repudiation
means the
accountability for users and/or principals for their actions for the
reason of
eventually resolve disputes about occurence or nonossurence of events or
acctions (this is
from OMGs security service document). What is behind that is a
possibility of
legal improvement for certain actions. this needs a non-repudiation
infrastructure (thats
what the security experts say) and thrusted third parties. It seems that
this
operaion cannot fulfill these requirements. So what is left is a certain
way of subscribing for
one service.And than, how is this related to subscription contract
creation?

Furthermore, how one can retirieve the agreement text. This is currently

not part of the select_service_operation, or of the service token. If
this goes with the
service token, than the textual description must contain the information
that the
"implementer" has to check the token is the additional
sign_service_agreement operation
must follow.
But still, I want before clarify if the service sign_service_agreement
operation is necesary, and
the select_service operation respectively.

The operations sign_service_agreement and select_service are deleted.