[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: User object in use cases, was: [provision] Agenda for 09/30/2002 PSTCcon-call
From what I could see though, the use cases that need a user object never in themselves use the data directly. I agreed with the discussion during the meeting that it could be tricky to try to impose a schema over the user data. Can the user data be different in order to capture specifics about the service being requested, or could it contain extra information related to personalization of the service? Could we instead say that there is a portion of the create PSU-ID request in which the user information should be sent, and recommend a few standards that could be used without imposing one? It also seemed that this was related to the cardinality of the PSU-ID to users in the PSP system. Since the RA can generate a PSU-ID, does that imply that the RA would control the cardinality, so that the PSP shouldn't even need to check the PSU data to verify whether this was a new or modified user? Or do we expect the PSP to associate multiple PSU-IDs with a single user by recognizing duplicates? My inclination is the former, as it seems that the latter, though perhaps easier to use, might be unnecessarily restrictive. Mike Polan IBM Canada Ltd |---------+--------------------------------> | | Yoav Kirsch | | | <Yoav.Kirsch@business| | | layers.com> | | | | | | 10/02/2002 06:55 AM | | | | |---------+--------------------------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| | | | To: "'Darran Rolls '" <Darran.Rolls@waveset.com>, "'provision@lists.oasis-open.org '" <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Agenda for 09/30/2002 PSTC con-call | | | | | >--------------------------------------------------------------------------------------------------------------------------------------------------| Darren, I recheck the use case and we should support user object. This is to support use cases 1-3, which deals with the PSP user management. Since this is the case I suggest that we PSP will support the LDAP user object. There are few reasons 1. LDAP user object is the most popular between the suggested standard. 2. Most of the provisioning tool out there today are based on LDAP directory and already support this entity. This will ease the integration between SPML and legacy provision systems Another issue While going over the use case document version 4 I notice that use case 1 appears twice ( as 1 and 2). also use case 15-17 have the same name and use cases 9,10. Yoav Kirsch Business Layers -----Original Message----- From: Darran Rolls To: provision@lists.oasis-open.org Sent: 9/30/02 12:14 AM Subject: [provision] Agenda for 09/30/2002 PSTC con-call CONFERENCE ID ============= Dial-in Number: 888-742-8686 Conference ID: 5250215 Date: 09/30/2002 Time 12 noon CDT. Proposed Agenda =============== 1 - 12:05 Order and role-call ------------------------------- 2 - 12:08 Vote to accept minutes of committee meeting 08/19/2002 ---------------------------------------------------------------- Minutes available [1]. 3 - 12:10 Update ---------------- Where are we on core specification development? Proposal for joint development initiatives. 5 - 12:20 Core Identity Schema ------------------------------ Discuss need for a core identity schema. Overview of that's out there. Suggestions/champions for investigation. 8 - 12:?? Motion to Adjourn --------------------------- [1] http://www.oasis-open.org/committees/provision/minutes/pstc-minutes-0819 <http://www.oasis-open.org/committees/provision/minutes/pstc-minutes-081 9> 2002.html -------------------------------------------------------- Darran Rolls http://www.waveset.com <http://www.waveset.com> Waveset Technologies Inc drolls@waveset.com (512) 657 8360 -------------------------------------------------------- Darran Rolls MSIM drolls_waveset@hotmail.com AIM drollswaveset YIM drolls_waveset <htp://www.waveset.com> http://www.waveset.com/ <mailto:drolls@waveset.com> drolls@waveset.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC