RE: [provision] First cut at the SPML schema to use for the interop

[Paul Madsen <p.madsen@entrust.com>]

Hi Jeff, 'Title' works, it does imply us agreeing on the list of allowed
values that make some sort of sense in the scenario context, e.g.
junior-contractor, senior-contractor, customer-relations, etc 

paul
>-----Original Message-----
>From: Jeff Bohren [mailto:jbohren@opennetwork.com]
>Sent: Thursday, June 05, 2003 3: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
>>
>