Figure 6-2 suggests that all of the association ends are navigable.
This contradicts the IDL, which shows that only some of the ends are
navigable.

Discussion: UML notation specifies placement of an arrow at the end of an
association line to indicate that the end is navigable, i.e. that an
instance on the other end can traverse to the navigable end.
(Unfortunately, the absence of any arrows on an association line can denote
either that both ends are navigable or that neither end is navigable.)
Usually if there is an association between class A and class B, and the end
on the B side is navigable, it means that a corresponding interface A has an
attribute that references a B. Consider, for example, the association
between ServiceProvider and ServiceTemplate in figure 6-2. The IDL shows
that ServiceTemplate has an attribute of type ProviderId, which is an
identifier for a Service Provider. Thus the ServiceProvider end of the
association is navigable. On the other hand, the IDL for ServiceProvider
does not have an attribute that references a ServiceTemplate. Therefore,
the ServiceTemplate end of the association is not navigable. Thus there
should be an arrow on the ServerProvider end of the association but not on
the ServiceTemplate end.

Recommendation: Refine this figure so that it specifies the navigability of
the associations correctly.

see above

the subscription segments specified here offer more functionality than
needed. They also
address (internal) administration functionality of the retailer to
manage subscription. We
therefore propose to replace this chapter with the new proposed
interfaces as follows
and move the current description either to an annex or delete it.

Due to the changes the text needs editorial work reflecting the changes.
(4.3.1, 4.4)

4.5.1.1 delete create_subscriber operation. This is done by the retailer
system administrator,
which needs this operation. Add a new interface InitialRegistration and
the operation
void register_me (in Subscriber, in end_user). this operation allows the
creation of subscriber
and end-users. The user has than the rigth to use further
segments.Should this go into the initial interface?
Replace in modify_subscriber operation the Subscriber by PropertyList
subscriber_properties.
The exceptions are related to properties, e.g. readonly etc.
When the administrator creates the new customer/subscriber, he gives the
subscriber
the right to use the subscriber admin related interfaces. No other user
can get access
to these segments.
Rename the delete_subscriber operation with unregister_me (). the
operation deactivates
all relationships the subscriber has. The result of this operation
is that all its users, contracts and profiles have to be deactivated
(not deleted as
there might be open bills etc.).

4.5.1.2 remove subscriberInfoQuery interface, add operation
get_subscriber to subscriberMgmt
interface, remove subscriberId from operation.

4.5.2.1 create_service_contract remove subscriber_id. the subscriber
only gets access with
the subscriber id. Add already exist exception
modify_service_contract, remove subscriber_id.

4.5.2.2 remove ServiceContractInforQuery interface, add operation
get_service_contact and
list_subscribed_services to ServiceContractMgmt interface, remove
SubscriberId from
both operations

4.6.1 rename deploy_service to register_service, remove ProviderId, as
the administrator
only provides this interface to srevice providers.

operation modify_service, add explanation that the provider can only
modify the service
properties. Is this operation necessary?

operation withdraw_service, rename to unregister_service, remove
providerId

Remove interface ServiceTemplateQuery annd add operations to
ServiceTemplateMgmt.
remove PorviderId, add for list_service_templates that this is a list of
retailer service templates.

4.7.1 move all operation related to SAGs to subscriber admin segment,
add new
UserManagement interface. Delete the interface SagInfoQuery, move
operations to
UserMgmt or SagMgmt

move create_sag, modify_sag, delete_sag, create_user, add_sag_users,
remove_sag_users
and from (4.7.1.2) list_sags, get_sag, list_sag_users to subscriber
admin segment. Delete
subscriberId as only the subscriber get the right for those interfaces
(from the administrator)

move operations modify_user, delete_user, get_user, list_users to
subscriber admin and
create a new interface UserMgmt for that. Replace in modify_user the
subscriberID and
endUser by userId user_id, userProperties user_properties, add new
operation
void modify_user_sec-props

raises PropertyError

4.7.2 move serviceProfileMgmt interface to subscriber administration
segment, delete
serviceProfileQuery interface (4.7.2.2) and move operations to
ServiceProfileMgmt
interface.
create_service_profile, delete SubscriberId as only the subscriber gets
this interface,
remove serviceProfileId, its part of serviceProfile
Modify_serviceProfile, remoce subscriberID,replace ServiceProfile by
ServiceProfileId
service_profile_id and PropertyList service_properties, only the service
properties can be
changed.

Remove subscriberId from all operations, as only the subscriber gets
these interfaces.
assign(), rename assign_service_profile, deassign rename
deassign_service_profile,
remove interface ServiceProfileInfoQuery, move operations to
serviceProfileMgmt
interface.
Remove subscriberId
delete list_assigned_users operation.

Add two new operation in Subscriber Segment; assign_sub_segment (in
SegmentID segment_id,
in SagId, sag_id), maybe in a new interface SubscriberAuthorisation ?
and add deassign_sub_segment (in SegmentID segment_id, in SagId,
sag_id). these operations are
used for assigning subscription segments to users. The subscriber may
want to authorise
more users to administer its entries. the authorisation can only be done
to a group,
(see information model), because only there is the for the profiles.

4.8.1 userProfileMgmt interface

modify_security_properties, remove SubscriberId and UserID,

rename modify_user_profile to modify_user_properties, remove
SubscriberId and UserID,

add void create_user_service_profile (in endUserServiceProfile end_user
_serviece_profile)
the user service profile can be empty.

modify_user_serviec_profile, remove SubscriberId and UserID,

delete_user_service_profile, remove SubscriberId and UserID,

get_user_description, delete description, remove remove SubscriberId and
UserID,
list_user_service_profile_ids, remove ids, remove SubscriberId and
UserID,
get_user_service_profile, remove SubscriberId and UserID,

delete UserProfileInfoQuery interface, move operations to
UserProfilemgmt.

see above

subscription as described in chapter 4 is specifying more than actually
needed. It specifies also internal interfaces. For that reason we
propose to move
the overall subscription description into an annex and reduce the
current specification to only
these interfaces and segments that are necessary.
The information model (4.2) should be changed as follows.

Figure 4.2 subscription information model. This has allways created a
lot of discussion. We want to simplify the information model as it
currently does not
reflect the idl. Delete all inheritance, remove the attributes from the
figure, add a
1-to1 relation between subscriber and serviceprovider, adda 1-to many
relation between
subscriber and enduser, add a 1-to-many relation between enduser and
sag.
delete the groupmember relation

4.2.3 replace in serviceContract service Profile by ServiceTypeName
service_type,
ServiceTemplate service_template and PropertyList service_properties and
change
the textuel description.
This is a result of simplifying (removing the inheritance) from the
object model (figure).

4.2.6 replace ServiceTypeName service_type, ServiceTemplate
service_template
by ServiceContractId service_contact_id and change the textuel
description
This is a result of simplifying (removing the inheritance) from the
object model (figure).

4.2.7 delete last sentence of first paragraph "end-user", it is no
longer valid.

Replaced in document and the text is revised according to the changes

2.3.1.6 end_session is this operation necessary, if so we need to add an

operation list_all_sessions to retrieve the identifiers.

see above

2.3.1.5 we have so many properties, but here we can replace them.
Replace the end_access_properties by enume for 1. all access session, 2.
all active
sessions, 3. only if no active sessions.

Accepted

3.2.1 why is there an extra release_segement. the core has an operation
release segment.

see above

2.3.1.9 release_segment

add token/credential for authentication reason.

Accepted

3.8 and 3.9 check notifications/events. Some are really dangerous if
given as notifications
back to the user.

see above

3.7.1.4 check if an additional operation get_service_info is needed like

in start_session.

see above

get_segment, rename to establish_segment. This is an exchange of
information between both sides. establish seems to be more
understandable. Add
token/ credential for authentication reason.

Accepted

2.3.1.7 list_segements, add token/credential for already authenticated
reason

Accepted

2.3.1.1 ServiceInfo contains the UserServiceName. The UserServiceName is

only
used here and not used in any other interface. Move this to the
ServicePropertyList.

Accepted

Section 2.2.2.2 authenticate challenge/response are of type string. Is
doesn't seem to be the right type used for encrypting data. Use e.g.
opaque as in the
CORBA security service specification.
There is a missing link between the authentication and the subsequent
request-access or the subsequent access interface references. As a
result of
authentication, a token or credentials should be added that can be used
as
input for request-access and the access segments (See also 2.2.1.2).

see above

· The get_segment method in TSAS loosely maps to the obtainInterface(WithCallback) methods in Parlay. However the former method permits the invoker to provide & obtain multiple interface references while the latter methods permit the invoker to provide & obtain at most one interface reference.
· The TSAS list_segments & release_segment methods have no equivalent in Parlay.
· [Figure 4.4, the first method invocation in the sequence diagram should be list_available_services, per the description that follows.]
· In TSAS, a service property does not contain a mode parameter.
· 4.2.1 Access interface, list_available_services: This method has no direct equivalent in Parlay. It has some similarities with the Parlay methods: IpDiscovery.listSubscribedServices (without the desired_properties filter) and IpDiscovery.discoverService (without the Service Type and "maximum # of matches" constraints).
· 4.2.1 Access interface, start_session, end_session: These TSAS methods have no equivalent in Parlay.
· 4.2.1 Access interface: TSAS does not support the Parlay accessCheck, terminateServiceAgreement and terminateAccess methods.
· 4.2.1 Access interface, sign_service_agreement: One of the return parameters (session_info) is a superset of the information returned by the corresponding parameter of the Parlay method; i.e. the latter returns at most one interface reference, no SessionID and no SessionProperty information.

Actions: no alignment with Parlay

While largely similar to the Parlay Trust & Security Management functions, there are a number of significant differences. In particular there are TSAS-defined methods that are not supported by Parlay 2.1, and vice versa. Also, where methods are common or at least similar in functionality, there are subtle differences in the parameter definitions. I have highlighted many of these as follows:

Section 4.1 Initial Contact and Authentication

· 4.1.1 Initial Interface, initiate_authentication: DomainId data type is a string in TSAS and a tagged union in Parlay
· 4.1.2 Authentication interface, select_auth_method: AuthCapabilityList is a "list of strings" in TSAS and a "string of (comma delineated) sub-strings" in Parlay

The issue is not longer relevant, no alignment with Parlay

3.5.1.2 end_access_sessions, add the options of end-access operation in
Core segment.

see above

3.4 delete context segment.
3.4.1.1 delete get_user_context and add exception in set_user_context
(3.4.1.2)

3.4.1.2 set_user_context move to new start segment before start_session.

Remove access_session_id form user_ctxt, it is not needed.

3.4.2.2 get_user_ctxts, is this operation needed? If so, move this to
access session control interface and add an operation list_user_ctxts

3.4.2.3 get_user_info, this is not relevant for the context. Move the
get_user_info to the new start segment. Check the user info structure
with subscription.
Currently they are different.

see above

TSAS Section 6 - [Optional] Subscription Segments
Much of this section is addressed by Parlay 2.1…again, there are significant differences, including the following:
· 6.1 Information model: many similarities with the Parlay information model, but notable discrepancies exist: e.g. service template.
· Most TSAS methods include subscriberID (or sometimes providerID) as an input parameter. This is not required in Parlay methods.
· 6.4.2 Service Contract Management, list_subscribed_services: This method has no direct equivalent in Parlay. It has some similarities with the Parlay method of the same name: IpDiscovery.listSubscribedServices , but the signatures differ substantially.
· 6.5 Service Provider administration, interface ServiceTemplateMgmt: This has some similarities with the Parlay Service Registration interface, but significant discrepancies exist.

no alignment with Parlay

3.7.1.1 list_service_sessions, the service_id is missing at
list_service_sessions. this id is needed for the resume. For which
reaon there is a session state? We don't need this.

see above

3.6, combine the ServiceDiscovery interface (and segment) and the
subscriber admin segment. The reaon for the service discovery is to
revieve
information about services and to subscribe them.
It makes sense to keep them together. See also the issue related to the
subscriber admin.

accepted

After the initial interface (well known) presents an authentication
interface to
a client, and the client successfully authenticates, the initial interface
is then
"opened" to respond to the request for service.

However there are no tokens or cookies passed to the client for subsequent
use
on the initial interface, so how does the initial interface know that the
client who
was authenticated is the client who asks for service?

At least clarify that the authentication only opens the initial interface
for the service
request phase for a small amount of time. Perhaps it would be better to
have some
token passed by the authentication to the client to use with the initial
interface.

Additional parameter introduced, see also issue 4088

suspend_session operation and suspend_my_participation are
missing.!!!!!!!!

Operation is added

3.3.1.3 the scenario seems a bit simplyfied. There is one party inviting

the user, that is not the provider. The inviter and the invitee may be
part of different
domains. The text for the operations explain a lot by using the
retailer. this should be
reflected in the diagramm.

the session_invitation needs additional infornation to which retailer it
belongs.

see above

For subscription we identifie that there is a need to extend the enum
for
exception code with one additional, generic error code. This results in
extending the exception SubscriptionError SubText string. This maybe
also useful for the other interfaces (segments)?

see above

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.

TSAS Section 5 - [Optional] Service Access Segments
Most of this section is not addressed by Parlay 2.1, with the exception of the Service Discovery segment…

Section 5.5 Service Discovery segment

· TSAS permits the retailer (Parlay framework) to invoke discovery functions on the service provider (Parlay service supplier). Only the opposite is supported in Parlay: i.e. the service supplier may invoke discovery functions on the framework.
· TSAS does not appear to support retrieval of, or selection by, Service Type. Specifically TSAS does not support the Parlay listServiceTypes and describeServiceType methods, or the Service Type parameter in the Parlay discoverService method.
· The TSAS get_service_info method has no close equivalent in Parlay.
· 5.5.1 ServiceDiscovery Interface, discover_services: The desired_properties parameter includes more filtering capabilities (use of Match & Which syntax) than the equivalent parameter in the Parlay discoverService method.
· 5.5.1 ServiceDiscovery Interface, discover_services: The return parameter (services) is a superset of the information returned by the corresponding parameter of the Parlay method; i.e. the latter does not return a service name attribute for each "discovered" service.

Section 2.2.1.2 request_access operation needs an additional parameter
to guarantee that the requestor has been authenticated. This shall be an

out parameter of authenticate (e.g. credentials). This parameter is also
missing in
each access segment.

see below

Section 2.2.1.1 initiate_authentication. What is the DomainId? Is it
necessary to do the authentication at a domain level. Isn't just the
select_auth_method (2.2.2.1) and authenticate (2.2.2.2) enough?

see above