[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
The pvSource doesn't look like something we would show in our demo, as opposed to the title which would be usefull. As I said before, if we use common things like title, we can use a standard schema, but if we use things like opvSource, it has to be 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 3: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 > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor kgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]