[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] First cut at the SPML schema to use for the interop
Probably right - I thought it might be nice to be able to see who's station input it. On contemplation it probably adds more complexity than it adds realistic value. I withdraw my proposal... ========================================================= Darran Rolls http://www.waveset.com Waveset Technologies Inc drolls@waveset.com (512) 657 8360 ========================================================= > -----Original Message----- > From: Paul Madsen [mailto:p.madsen@entrust.com] > Sent: Thursday, June 05, 2003 2:40 PM > To: Darran Rolls; provision@lists.oasis-open.org > Subject: RE: [provision] First cut at the SPML schema to use for the > interop > > Darran, wrt the 'pvSource' attribute, isn't it immaterial from which work > station the IU happened to be at when they submitted the information? They > are really not submitting it from ENTU (for example), its a coincidence > that > Entrust software happens to be installed on that machine. > > How would Peoplesoft be sensitive to this in order to populate the > attribute, from the IP of the browser? > > Paul > > >-----Original Message----- > >From: Darran Rolls [mailto:Darran.Rolls@waveset.com] > >Sent: Thursday, June 05, 2003 3:33 PM > >To: Jeff Bohren; Paul Madsen; provision@lists.oasis-open.org > >Subject: RE: [provision] First cut at the SPML schema to use for the > >interop > > > > > >To be clear, this is the service schema from the Mycroft Multiplexer to > >the downstream PSP/PST's and not a "standards schema" that we would > >include in the TC process - right? > > > >I too like the idea of generic HR related attribute that is > >input by the > >user at the HRMS portal which flows down into each PSP as is > >interpreted > >in an appropriate manner locally to define some degree of "onward > >provisioning" and/or access control. > > > >I'd also like to propose an attribute that documents "this user was > >input from the following vendor's work station"... Something like: > > > ><attr name="pvSource"> > > <value>CP|ONT|Waveset|PSFT|BMC|Sun|ENU|Thor</value> > ></attr> > > > >========================================================= > >Darran Rolls http://www.waveset.com > >Director of Technology drolls@waveset.com > >Waveset Technologies Inc (512 657 8360) > >========================================================= > > > >> -----Original Message----- > >> From: Jeff Bohren [mailto:jbohren@opennetwork.com] > >> Sent: Thursday, June 05, 2003 2:10 PM > >> To: Paul Madsen; provision@lists.oasis-open.org > >> Subject: RE: [provision] First cut at the SPML schema to use for the > >> interop > >> > >> Paul, > >> > >> I agree that we need some kind of attribute to indicate > >authorization. > >> This is why I was leary of trying to use an "alpha version" of a > >> standard schema for the interop demo. If we use an alpha version > >> standard schema, then we should limit ourself to attributes > >that would > >> make sense in the final schema. If we use a custom schema, > >or a custom > >> schema that extends the alpha version standard schema, then we have > >more > >> more flexibility. > >> > >> How about "title" to perform authorization? That would make > >sense in a > >> standard schema as well. If we do something like accesslevel or > >> contractlimit, then we really need to create a custom schema. > >> > >> Jeff Bohren > >> Product Architect > >> OpenNetwork Technologies, Inc > >> > >> > >> > >> -----Original Message----- > >> From: Paul Madsen [mailto:p.madsen@entrust.com] > >> Sent: Thursday, June 05, 2003 2:57 PM > >> To: Jeff Bohren; provision@lists.oasis-open.org > >> Subject: RE: [provision] First cut at the SPML schema to use for the > >> interop > >> > >> > >> Hi Jeff, comments on first draft of interop schema > >> > >> 1) I'd like to see an attribute that could carry some aspect of > >> authorization, e.g. role, level, userType etc. We need this > >information > >> communicatetd in some manner so that we can subsequently apply > >> appropriate access control based on it. > >> > >> Although the 'description' attribute in the current schema could > >serve, > >> given that the SPML messages will at some point likely be > >displayed to > >> the attendees, it would be preferable to have a more logical name for > >> the attribute > >> > >> Perhaps we can avoid the issue of determining a list of meaningful > >> values for this attribute by using simple integer values, e.g. > >> > >> <attr name="accessLevel"> > >> <value>1|2|3|4|5</value> > >> </attr> > >> > >> or, perhaps more relevant to the scenario, > >> > >> <attr name="contractLimit"> > >> <value>1000|10,000|100,000</value> > >> </attr> > >> > >> 2) only the 'cn' attribute is listed as required. Related to point 1) > >- > >> we would need the 'accessLevel' attribute (or whatever it is called) > >to > >> be required as well.) More generally, we should make all attributes > >that > >> a PSP will 'use' to be required. I don't think we want to be in the > >> situation of saying 'well if you had set this attribute in the form, > >you > >> would have seen ........' > >> > >> We will need to of course balance this against the usability issue of > >> having an attendee populating a long form with a wine glass in one > >hand > >> and hor d'ouerves in another. Hopefully multiple PSPs will be able to > >> leverage shared attributes. > >> > >> Paul > >> > >> >-----Original Message----- > >> >From: Jeff Bohren [mailto:jbohren@opennetwork.com] > >> >Sent: Wednesday, June 04, 2003 10:22 PM > >> >To: provision@lists.oasis-open.org > >> >Subject: [provision] First cut at the SPML schema to use for > >> >the interop > >> > > >> > > >> >I apologize for just now getting to this. Attached is a first > >> >cut of an SPML schema for the interop. > >> > > >> > > >> >Jeff Bohren > >> >OpenNetwork Technologies > >> > > >> > >> You may leave a Technical Committee at any time by visiting > >> http://www.oasis- > >> open.org/apps/org/workgroup/provision/members/leave_workgroup.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]