Issues for Telecommunications Service Access and Subscription (TSAS) FTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3727: Figure 6-2 suggests that all of the association ends are navigable
Issue 4061: issue of access control
Issue 4069: Section 4.1 Initial Contact and Authentication
Issue 4070: Section 4.2 Access
Issue 4071: Section 5.5 Service Discovery segment
Issue 4072: TSAS Section 6 - [Optional] Subscription Segments
Issue 4087: exception code issue
Issue 4088: Section 2.2.1.1 initiate_authentication
Issue 4089: Section 2.2.1.2 request_access operation needs an additional parameter
Issue 4090: Section 2.2.2.2 authenticate challenge/response are of type string
Issue 4091: 2.3.1.1 ServiceInfo contains the UserServiceName
Issue 4092: 2.3.1.1, 2.3.1.2, 2.3.1.3 and 2.3.1.4
Issue 4093: Replace properties
Issue 4094: 2.3.1.6 end_session is this operation necessary?
Issue 4095: 2.3.1.7 list_segements
Issue 4096: get_segment, rename to establish_segment
Issue 4097: 2.3.1.9 release_segment
Issue 4098: 3.2.1 why is there an extra release_segement
Issue 4099: 3.3.1.3 the scenario seems a bit simplyfied
Issue 4100: 3.4 delete context segment
Issue 4101: 3.5.1.2 end_access_sessions
Issue 4102: 3.6 combine the ServiceDiscovery interface and subscriber admin segment
Issue 4103: 3.7.1.1 list_service_sessions
Issue 4104: suspend_session operation and suspend_my_participation are missing
Issue 4105: 3.7.1.4 check if an additional operation get_service_info is needed
Issue 4106: 3.8 and 3.9 check notifications/events
Issue 4107: subscription as described in chapter 4 is specifying more than needed
Issue 4108: Subscription segments specified here offer more functionallity than needed

Issue 3727: Figure 6-2 suggests that all of the association ends are navigable (tsas-ftf)

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.

The Figure is only one example. It is simplified now and only describes the association between the classes.

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.

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 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.

The issue is not longer relevant. Some of the operations are not supported in Parlay. On the other hand, Parlay works with call backs, which makes it in several cases difficult to align with them. In addition to that they also have emerging standards, getting more and more revisions for each new version, which also makes it difficult to align.

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.

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.

Parlay is an ongoing emerging standard which makes it difficult to align. Parlay has only parts of subscription which they are going to extent

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)?

Proposal:

Add additional exception in exception code for not yet identified errors, which allows furhter extention.

Module	Enum Exception code	action	Exception 	description
module sub	enum SubExceptionCode	add 	subInternalsubOther	
module DfTsas	enum AuthErrorCode	add	authOther	
	enum AccessErrorCode	add	accOther;	
	exception AuthError	add	string description;	
	enum AccessErrorCode	add	accOther	
	exception AccessError	add	string description	

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?

Resolution: 
The authentication interface allows the definition of arbitrary authentication protocols. If both a domain authentication and a user authentication are required a related authentication type (auth_type) can be defined. The TSAS default authentication is a user authentication.
Revised Text: 
		void initiate_authentication (
in Object  user_authentication,
in AuthType  auth_type,
out Object provider_authentication)
raises ( AuthError );
The user uses this method to initiate the authentication process.
user_authentication  is a reference to an authentication interface at the user domain that can be invoked by the provider to perform the authentication procedure.This interface can be nil, the TSAS Authentication interface, or an authentication protocol specific interface. In case of the default TSAS authentication it is a nil reference.
auth_type identifies the type of authentication mechanism requested by the user. It provides users and providers with the opportunity to use an alternative to the TSAS Authentication interface (for example, CORBA Security). This authentication process may be specific to the TSAS provider. The "TSAS_AUTHENTICATION" provided by the authentication interface is the default authentication method.
If the CORBA Security Service is supported by both the user and the provider, then it may be used to mutually authenticate the user and the provider. The operation of the CORBA security service is out of the scope of TSAS. If it is used to provide authentication of the parties, then the "CORBA_SECURITY" value is used for the auth_type attribute, and no further authentication is required. 
However, if the CORBA Security Service is not supported by both parties, and if further authentication is required, then the TSAS Authentication interface can be used. It is obtained by filling the auth_type attribute with the value "TSAS_AUTHENTICATION".
The operation returns the provider_authentication, a reference to an authentication interface at the provider domain that has to be invoked by the user to perform the authentication procedure. This interface can be the TSAS Authentication interface (default), or an authentication protocol specific interface

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.

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).

Accepted, the challenge/response parameter type has been changed. A credential parameter has been added

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.

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.

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.

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.

Rejected. The operation start_session returns a session_id. An operation list_service_sessions is part of the session controll interface

2.3.1.7 list_segements, add token/credential for already authenticated
reason

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.

2.3.1.9 release_segment

add token/credential for authentication reason.

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

Resolution: 
While the release_segments operation of the access segment is a factory type operation the release_segment operation is supported by every interface instance. 
The definition of the base interface has been moved into section 2.3

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.

The current TSAS specification focuses on single party services. Multi party services will be addresses in a separate RFP. Thus the invitation segment is deleted.

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.

The segmented has been deleted. The definition of the user context and the retrieval of the user info are included in the request_access operation.

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

It is hardly recommended to delete the whole access control segment. The user has the possibility to control every access session in the context of this session. If it is necessary to control something like a meta-access session this should be done on the application level and not as part of TSAS.

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.

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.

The general information about access or service sessions are given by the respective control segments providing control interfaces that the user is able to obtain information about
running access sessions using the list_access_session operation that returns a
list of access session infos. Additional he can obtain information about the
service sessions that are running in the contexts of one of his access sessions
using the operation list_service_sessions, that returns a list of service
session infos.

It is hardly recommended to change the signature of both operations in a way,
that they return only the ids , states, and properties of the sessions. 

void list_access_sessions (out AccessSessionIdList as_id_list);

typedef struct SessionDescription {
SessionId session_id,
SessionState session_state,
SessionPropertyList session_properties};

void list_service_sessions 
        (in ...,
out ServiceDescriptionList service_description_list);

This restriction ensures, that a user has only control about the service
sessions, that have been established in his current access session. The session
infos that are currently returned give the user much more control over non-local
sessions.
New text:
void  list_service_sessions (
							in Opaque session_token,
							in AccessSessionId as_id,
							in SessionSearchProperties  desired_properties,
							out SessionDescriptionList session_description_list,
						) raises (
							PropertyError,
							ListError
);
The list_service_sessions() returns a SessionList (list of sessions) of the specified access session as_id. This includes active and suspended sessions. A session is associated with an access session if it is being used within that access session, or if it has been suspended in an arbitrary access session.
The desired_properties parameter can be used to scope the list of sessions. It identifies the properties that the sessions must match. It also defines whether a session must match one, all or none of the properties (see MatchProperties in Section  ...  on page  ... ). The following property names and values have been defined for SessionSearchProperties:
If a property in SessionSearchProperties has the name "SessionState," then the matching service session must have the same SessionState as given in the property value.
	name: "SessionState"
	value: UserSessionState ("active" or "suspended")
Other provider specific properties can also be defined in desired_properties.
The list of sessions matching the desired_properties are returned in sessions. This is a sequence of SessionDescription structures which define the SessionId, the SessionState, and a series of provider specific properties. This information is provider specific, and consequently out of the scope of TSAS.
If the desired_properties parameter is wrongly formatted, or provides an invalid property name or value, the PropertyError exception should be raised. Property names that are not recognized can be ignored if desired_properties requires that only some, or none of the properties are matched.
If the sessions list is unavailable because the end-user's sessions are not known, then the operation should raise a ListError exception with the ListUnavailable error code.

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

3.7.1.4 check if an additional operation get_service_info is needed like

in start_session.

Resolution:
This operation can be used to return service specific information that is needed to launch the service GUI or to display information about the service itself. It is moved to the access interface.

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

Resolution:
One of the general concepts of the TSAS specification determines, that
information exchange between a user and a provider is only possible in the
context of an established access session between both parties. Using
COS-mechanisms to send notifications about changes in the state of access and
service session breaks this rule. For this reason we introduce a new segment, the session information segment, which replaces the access session information segment and the servive session information segment (chapter 3.8 and 3.9).               

interface SessionInformation:SegmentBase {...};

This user provided interface is returned as a result of the Core::Access::get_segment() operation. To be able to provide this interface, the user must be implemented as a CORBA server. If the user does not want to provide such an interface he is able to obtain information about running sessions polling the control segments, provided by the provider. 
Using this interface the provider can signal changes of the state of user related sessions. Because these are only notifications they are specified as oneways.

oneway void new_access_session_info (in AccessSessionId as_id);
oneway void end_access_session_info (in AccessSessionId as_id);

It is not necessary, to distinguish different reasons for the termination of an
access session. Changes in the amount of usable services have to be handled by other means than sending notification in the case of new available services.

The following notifications are meaningful because sessions can be terminated or
suspended from the service itself and not only from the session control interface:

oneway void end_session_info (in SessionId ss_id);
oneway void suspend_session_info (in SessionId ss_id);

Notifications in case of the start, and resumption of sessions are not
meanigful, because these operations are triggered by the user in the local
access session via the session control interface. Sessions belonging to other
access session are of no interest.
Revised text:
Delete chapter 3.8 and 3.9 and add new chapter 3.8 as follows:

3.8 Session Information Segment.
This segment is defined to allow a provider (in the general sense) to inform a user (in the general sense) of changes of state in other access sessions and service with the same user (for example, access sessions with the same user that are created or deleted). The user is only informed about the access sessions he is involved in. 
If the user does not want to provide such an interface he is able to obtain information about running sessions polling the control segments, provided by the provider.
Session Information Interface
interface SessionInformation :: SegmentBase 
{ ...
};
The SessionInformation  interface allows a user to receive notifications about session changes. This interface is returned as a result of the Core::Access::get_segment () operation. Using this interface the provider can signal changes of the state of user related sessions. Because these are only notifications they are specified as oneways.
new_access_session_info
oneway void new_access_session_info (
							in AccessSessionId as_id
);
The user gets information about a new access session, started with his own user identification. The as_id is an identifier for the new access session.
end_access_session_info
oneway void end_access_session_info (
							in AccessSessionId as_id
);
The user gets information about a terminated access session The  as_id is the identifier of the terminated access session.
end_session_info
oneway void end_session_info (
							in SessionId session_id
);
The user gets information about a terminated service session The session_id is the identifier of the terminated service session.
					
suspend_session_info
oneway void suspend_session_info (
							in SessionId session_id
);
The user gets information about a suspended service session The  session_id is the identifier of the suspended service session.

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.

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 {in UserId user_id, in PropertyList
security_properties}
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.

According to the discussion in the issue the subscription part has been reviewed. All query interfaces have been deleted, they are not necessary. The operations from the query interfaces are moved to the management interfaces. 
A new segment has been introduced to allow a subscriber to register itself.
The subscriber administration segment has now 5 interfaces, the subscriber management interface to modify and unregistered subscribers and to retrieve subscriber related information.
The service contract Management interface allows subscribers to do all operations necessary for contracts. The Sag Management interface allows a subscriber to manage it subscription assignment groups and the user management allows subscribers to manage its users. The authorization management interface is used by subscribers to authorize its users for using services.
The service discovery segment has been taken from the access segments to the subscription segments.

According to the proposal in the issue, all operation have been moved to the respective interface, which can be seen in the document. This is a total change of the subscription section, therefore it is not provided here.

Some general comments are discussed here. For all operations at the subscriber administration segment, the subscriber ID is removed. The reason is, that only the subscriber can retrieve these interfaces. Therefore there is no need to separately identify the subscriber. The same is valid for the service provider segment, there is no need for a service provider ID and for the end user customisation segment, there is no need to identify the user.

The following operations have been renamed
Previous document	New document
create_subscriber	register_me
Deploy_service	Register_service
Withdraw_service	Unregister_service
Delete_subscriber	Unregister_me
Add_sag_users	Add_sag_named_entities
Remove_sag_users	Remove_sag_named_entities
List_sag_named_users	List_sag_named_entities
Interface serviceProfileMgmt	Interface AuthorizationMgmt
	

The reason for renaming create_subscriber, deploy_service, withdraw_service and delete subscriber to register_me, Register_service, Unregister_service, Unregister_me was a discussion about a better meaning of the operations. 

To rename user as named-entities in Add_sag_users, Remove_sag_users, List_sag_named_users has its reason in having an additional named-entity, which can serve as either user_id or group_id and simplifies the assignment of user or user groups to subscription assignment groups.

The reason for renaming the service profile management interface to authorizaion management interface is simply because the operations are used to authorize the user to use a service the subscriber has subscribed for.