${taskforce.name} Avatar
  1. OMG Task Force

TSAS FTF — All Issues

  • Key: TSAS
  • Issues Count: 28
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
TSAS-28 Figure 6-2 suggests that all of the association ends are navigable TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-27 Subscription segments specified here offer more functionallity than needed TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-26 subscription as described in chapter 4 is specifying more than needed TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-13 2.3.1.6 end_session is this operation necessary? TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-12 Replace properties TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-17 3.2.1 why is there an extra release_segement TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-16 2.3.1.9 release_segment TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-25 3.8 and 3.9 check notifications/events TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-24 3.7.1.4 check if an additional operation get_service_info is needed TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-15 get_segment, rename to establish_segment TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-14 2.3.1.7 list_segements TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-10 2.3.1.1 ServiceInfo contains the UserServiceName TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-9 Section 2.2.2.2 authenticate challenge/response are of type string TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-4 Section 4.2 Access TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-3 Section 4.1 Initial Contact and Authentication TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-20 3.5.1.2 end_access_sessions TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-19 3.4 delete context segment TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-5 TSAS Section 6 - [Optional] Subscription Segments TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-22 3.7.1.1 list_service_sessions TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-21 3.6 combine the ServiceDiscovery interface and subscriber admin segment TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-2 issue of access control TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-23 suspend_session operation and suspend_my_participation are missing TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-18 3.3.1.3 the scenario seems a bit simplyfied TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-6 exception code issue TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-11 2.3.1.1, 2.3.1.2, 2.3.1.3 and 2.3.1.4 TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-1 Section 5.5 Service Discovery segment TSAS 1.0b1 open
TSAS-8 Section 2.2.1.2 request_access operation needs an additional parameter TSAS 1.0b1 TSAS 1.0 Resolved closed
TSAS-7 Section 2.2.1.1 initiate_authentication TSAS 1.0b1 TSAS 1.0 Resolved closed

Issues Descriptions

Figure 6-2 suggests that all of the association ends are navigable

  • Key: TSAS-28
  • Legacy Issue Number: 3727
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Wed, 28 Jun 2000 04:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:46 GMT

Subscription segments specified here offer more functionallity than needed

  • Key: TSAS-27
  • Legacy Issue Number: 4108
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

subscription as described in chapter 4 is specifying more than needed

  • Key: TSAS-26
  • Legacy Issue Number: 4107
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.3.1.6 end_session is this operation necessary?

  • Key: TSAS-13
  • Legacy Issue Number: 4094
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace properties

  • Key: TSAS-12
  • Legacy Issue Number: 4093
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.2.1 why is there an extra release_segement

  • Key: TSAS-17
  • Legacy Issue Number: 4098
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

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

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.3.1.9 release_segment

  • Key: TSAS-16
  • Legacy Issue Number: 4097
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    2.3.1.9 release_segment

    add token/credential for authentication reason.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.8 and 3.9 check notifications/events

  • Key: TSAS-25
  • Legacy Issue Number: 4106
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

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

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.7.1.4 check if an additional operation get_service_info is needed

  • Key: TSAS-24
  • Legacy Issue Number: 4105
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    3.7.1.4 check if an additional operation get_service_info is needed like

    in start_session.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_segment, rename to establish_segment

  • Key: TSAS-15
  • Legacy Issue Number: 4096
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.3.1.7 list_segements

  • Key: TSAS-14
  • Legacy Issue Number: 4095
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    2.3.1.7 list_segements, add token/credential for already authenticated
    reason

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.3.1.1 ServiceInfo contains the UserServiceName

  • Key: TSAS-10
  • Legacy Issue Number: 4091
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.2.2.2 authenticate challenge/response are of type string

  • Key: TSAS-9
  • Legacy Issue Number: 4090
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

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

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 4.2 Access

  • Key: TSAS-4
  • Legacy Issue Number: 4070
  • Status: closed  
  • Source: Anonymous
  • Summary:

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

  • Reported: TSAS 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Actions: no alignment with Parlay

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 4.1 Initial Contact and Authentication

  • Key: TSAS-3
  • Legacy Issue Number: 4069
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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

  • Reported: TSAS 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    The issue is not longer relevant, no alignment with Parlay

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.5.1.2 end_access_sessions

  • Key: TSAS-20
  • Legacy Issue Number: 4101
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

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

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.4 delete context segment

  • Key: TSAS-19
  • Legacy Issue Number: 4100
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TSAS Section 6 - [Optional] Subscription Segments

  • Key: TSAS-5
  • Legacy Issue Number: 4072
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    no alignment with Parlay

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.7.1.1 list_service_sessions

  • Key: TSAS-22
  • Legacy Issue Number: 4103
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.6 combine the ServiceDiscovery interface and subscriber admin segment

  • Key: TSAS-21
  • Legacy Issue Number: 4102
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

issue of access control

  • Key: TSAS-2
  • Legacy Issue Number: 4061
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Mon, 20 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Additional parameter introduced, see also issue 4088

  • Updated: Fri, 6 Mar 2015 20:58 GMT

suspend_session operation and suspend_my_participation are missing

  • Key: TSAS-23
  • Legacy Issue Number: 4104
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

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

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    Operation is added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

3.3.1.3 the scenario seems a bit simplyfied

  • Key: TSAS-18
  • Legacy Issue Number: 4099
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

exception code issue

  • Key: TSAS-6
  • Legacy Issue Number: 4087
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

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

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2.3.1.1, 2.3.1.2, 2.3.1.3 and 2.3.1.4

  • Key: TSAS-11
  • Legacy Issue Number: 4092
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    The operations sign_service_agreement and select_service are deleted.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.5 Service Discovery segment

  • Key: TSAS-1
  • Legacy Issue Number: 4071
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.2.1.2 request_access operation needs an additional parameter

  • Key: TSAS-8
  • Legacy Issue Number: 4089
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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.

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.2.1.1 initiate_authentication

  • Key: TSAS-7
  • Legacy Issue Number: 4088
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Linda Strick)
  • Summary:

    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?

  • Reported: TSAS 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — TSAS 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT