Issue 4118: Multiple Privilege Authorities and Supported Naming Types (csiv2-ftf) Source: Syracuse University (Dr. Polar Humenn, polar(at)adiron.com) Nature: Uncategorized Issue Severity: Summary: Multiple privilege authorities and multiple naming types yield combinatorial problems for the client. Discussion: This issue is sort of in the same regards to Issue 3973 where Ron thinks that having multiple target_name(s) in the AS_ContextSec is a bad idea, of which I agree. The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec structure sequence<ServiceConfiguration>. It suffers the same problem, especially when combined with multiple supported naming types. It is completely hard to determine having multiple privilege authorities and the names that must be used to assert the identity for the privileges. In fact, the client may get back an AuthorizationToken that he doesn't understand, but will need to assert an identity for it's use, quite possibly with endorsement. Having multiple naming types supported per privilege authority is fine, but combine that with multiple ones, and you may get a decision problem for the client. It is better to be able to specify a one-to-one correspondence, locking down the combinations that a server will accept, and the client doesn't have to do any mucking about deciding what will work. Proposed Solution: Singularize the privilege authorities field. Unfortunately IDL has a hard time making a singular field become optional without doing something bizzare, such as: switch(boolean) { true: ServiceConfiguration privilege_authority } which requires a new type, etc. I have two proposals: Proposal 1: We signularize the field in name, i.e. "privilege_authority". Keep the sequence definition. However, stating in the specification at most one must be contained. This can be hinted at as well in IDL. struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; sequence <ServiceConfiguration,1> privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }; Proposal 2: We specify a ServiceConfigurationSyntax tag for "none", and specify that the sequence of octet associated with it is empty. // Corresponding ServiceName for the SCS_None Syntax should be an empty // sequence octets. const ServiceConfigurationSyntax SCS_None = -1; struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceConfiguration privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }; For efficiency I'm in favor of the second approach, because I can just look a the ServiceConfiguration::syntax field and know what to do. The first proposal causes me to look at the length first, index to the first element in the array, and then look at the syntax field. As an aside, I also wouldn't mind changing the sequence<Security::OID> type into a Security::OIDList, but that can be the subject of another issue. Also note, to be specific with the document I am pointing to, I used the "Security" definitions. Hopefully, we will follow one proposal to change the Security::AssociationOptions to CSIIOP::AssociationOptions and Security::OID and Security::OIDList to CSI::OID and CSI::OIDList respectively. Resolution: Close issue with revised text. Revised Text: Base document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf [1] Replace Paragraph 148 with the following two paragraphs: The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. A CSS shall not be required to look beyond the first element of this sequence unless required by the first element. The syntax field within the ServiceConfiguration element identifies the format used to represent the authority. Two alternative formats are currently defined: an ASN.1 encoding of the GeneralNames (as defined in [IETF RFC 2459]) which identify a privilege authority, or a GSS exported name (as defined in [IETF RFC 2743] Section 3.2) encoding of the name of a privilege authority. Actions Taken: Actions taken: January 10, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Jan 2001 18:46:53 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org cc: issues@omg.org Subject: Issue: Multiple Privilege Authorities and Supported Naming Types Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: l"f!!pQj!!H)#!!R?*e9 Issue Subject : Multiple Privilege Authorities and Supported Naming Types Document: http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf Summary: Multiple privilege authorities and multiple naming types yield combinatorial problems for the client. Discussion: This issue is sort of in the same regards to Issue 3973 where Ron thinks that having multiple target_name(s) in the AS_ContextSec is a bad idea, of which I agree. The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec structure sequence. It suffers the same problem, especially when combined with multiple supported naming types. It is completely hard to determine having multiple privilege authorities and the names that must be used to assert the identity for the privileges. In fact, the client may get back an AuthorizationToken that he doesn't understand, but will need to assert an identity for it's use, quite possibly with endorsement. Having multiple naming types supported per privilege authority is fine, but combine that with multiple ones, and you may get a decision problem for the client. It is better to be able to specify a one-to-one correspondence, locking down the combinations that a server will accept, and the client doesn't have to do any mucking about deciding what will work. Proposed Solution: Singularize the privilege authorities field. Unfortunately IDL has a hard time making a singular field become optional without doing something bizzare, such as: switch(boolean) { true: ServiceConfiguration privilege_authority } which requires a new type, etc. I have two proposals: Proposal 1: We signularize the field in name, i.e. "privilege_authority". Keep the sequence definition. However, stating in the specification at most one must be contained. This can be hinted at as well in IDL. struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; sequence privilege_authority; sequence supported_naming_mechanisms; }; Proposal 2: We specify a ServiceConfigurationSyntax tag for "none", and specify that the sequence of octet associated with it is empty. // Corresponding ServiceName for the SCS_None Syntax should be an empty // sequence octets. const ServiceConfigurationSyntax SCS_None = -1; struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceConfiguration privilege_authority; sequence supported_naming_mechanisms; }; For efficiency I'm in favor of the second approach, because I can just look a the ServiceConfiguration::syntax field and know what to do. The first proposal causes me to look at the length first, index to the first element in the array, and then look at the syntax field. As an aside, I also wouldn't mind changing the sequence type into a Security::OIDList, but that can be the subject of another issue. Also note, to be specific with the document I am pointing to, I used the "Security" definitions. Hopefully, we will follow one proposal to change the Security::AssociationOptions to CSIIOP::AssociationOptions and Security::OID and Security::OIDList to CSI::OID and CSI::OIDList respectively. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Thu, 11 Jan 2001 11:03:06 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: csiv2-ftf@omg.org, issues@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;Aj!!)Fpd9Cg7e9G#H!! Polar Humenn wrote: > > Issue > > Subject : Multiple Privilege Authorities and Supported Naming Types > > Document: http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf > > Summary: > > Multiple privilege authorities and multiple naming types yield > combinatorial problems for the client. > > Discussion: > > This issue is sort of in the same regards to Issue 3973 where Ron thinks > that having multiple target_name(s) in the AS_ContextSec is a bad idea, of > which I agree. > > The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec > structure sequence. It suffers the same problem, > especially when combined with multiple supported naming types. > > It is completely hard to determine having multiple privilege authorities > and the names that must be used to assert the identity for the privileges. > In fact, the client may get back an AuthorizationToken that he doesn't > understand, but will need to assert an identity for it's use, quite > possibly with endorsement. Having multiple naming types supported per > privilege authority is fine, but combine that with multiple ones, and you > may get a decision problem for the client. > > It is better to be able to specify a one-to-one correspondence, locking > down the combinations that a server will accept, and the client doesn't > have to do any mucking about deciding what will work. > > Proposed Solution: > > Singularize the privilege authorities field. > > Unfortunately IDL has a hard time making a singular field become optional > without doing something bizzare, such as: > switch(boolean) { > true: ServiceConfiguration privilege_authority > } > which requires a new type, etc. > > I have two proposals: > > Proposal 1: > > We signularize the field in name, i.e. "privilege_authority". Keep the > sequence definition. However, stating in the specification at most one > must be contained. This can be hinted at as well in IDL. > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence privilege_authority; > sequence supported_naming_mechanisms; > }; > > Proposal 2: > > We specify a ServiceConfigurationSyntax tag for "none", and specify that > the sequence of octet associated with it is empty. > > // Corresponding ServiceName for the SCS_None Syntax should be an empty > // sequence octets. > const ServiceConfigurationSyntax SCS_None = -1; > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > ServiceConfiguration privilege_authority; > sequence supported_naming_mechanisms; > }; > > For efficiency I'm in favor of the second approach, because I can just > look a the ServiceConfiguration::syntax field and know what to do. The > first proposal causes me to look at the length first, index to the first > element in the array, and then look at the syntax field. The argument for changing target name to singular in a mechanism, is that a target which supports more than one target name, most likely does so because it supports more than 1 authentication mechanim. An alternate way to accomplish the same thing would simply be to add another mechanism definition to its mechanism list. If the issue Polar raises is a problem, and I can see how it could be, then I would suggest we restrict all the privilege authorities within a given mechanism definition to the same type. If we do this, then there is another possibility, which will preserve the ability to name multiple privilege authorities of the same syntax within a single mechanism. That is: struct SAS_ContextSec{ Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceSpecificName privilege_authority_syntax; sequence privilege_authorities; sequence supported_naming_mechanisms; }; We would discard the ServiceConfiguration type. The existing semantics of the length of the privilege_authorities sequence being used to detect if there are privilege authorities specified would be maintained. When the length of the sequnence is 0, the syntax value would be irrelevant. > > As an aside, I also wouldn't mind changing the > sequence > type into a Security::OIDList, but that can be the subject of > another > issue. Also note, to be specific with the document I am pointing to, > I > used the "Security" definitions. Hopefully, we will follow one > proposal to > change the Security::AssociationOptions to > CSIIOP::AssociationOptions and > Security::OID and Security::OIDList to CSI::OID and CSI::OIDList > respectively. > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com Date: Thu, 11 Jan 2001 11:10:20 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Ron Monzillo CC: Polar Humenn , csiv2-ftf@omg.org, issues@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types References: <3A5DD93A.7CF6F949@east.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: hR*e93@*!!iT;!!7*b!! Ron Monzillo wrote: > see the ----->, where I meant to write the following > That is: > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; -----> ServiceSpecificSyntax > privilege_authority_syntax; > sequence > privilege_authorities; > sequence > supported_naming_mechanisms; > }; > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 11 Jan 2001 11:32:41 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org, issues@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types In-Reply-To: <3A5DD93A.7CF6F949@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: *6:!!%?Wd9[3N!!Tb8e9 Greetings, I am NOT in favor of Ron's approach on this issue. Comments below. -Polar On Thu, 11 Jan 2001, Ron Monzillo wrote: > > > Polar Humenn wrote: > > > > Issue > > > > Subject : Multiple Privilege Authorities and Supported Naming > Types > > > > Document: http://cgi.omg.org/pub/csiv2-ftf/draft-adopted-spec.pdf > > > > Summary: > > > > Multiple privilege authorities and multiple naming types yield > > combinatorial problems for the client. > > > > Discussion: > > > > This issue is sort of in the same regards to Issue 3973 where Ron > thinks > > that having multiple target_name(s) in the AS_ContextSec is a bad > idea, of > > which I agree. > > > > The type of the privilege_authorities field in the > CSIIOP::SAS_ContextSec > > structure sequence. It suffers the same > problem, > > especially when combined with multiple supported naming types. > > > > It is completely hard to determine having multiple privilege > authorities > > and the names that must be used to assert the identity for the > privileges. > > In fact, the client may get back an AuthorizationToken that he > doesn't > > understand, but will need to assert an identity for it's use, > quite > > possibly with endorsement. Having multiple naming types supported > per > > privilege authority is fine, but combine that with multiple ones, > and you > > may get a decision problem for the client. > > > > It is better to be able to specify a one-to-one correspondence, > locking > > down the combinations that a server will accept, and the client > doesn't > > have to do any mucking about deciding what will work. > > > > Proposed Solution: > > > > Singularize the privilege authorities field. > > > > Unfortunately IDL has a hard time making a singular field become > optional > > without doing something bizzare, such as: > > switch(boolean) { > > true: ServiceConfiguration privilege_authority > > } > > which requires a new type, etc. > > > > I have two proposals: > > > > Proposal 1: > > > > We signularize the field in name, i.e. > "privilege_authority". Keep the > > sequence definition. However, stating in the specification at most > one > > must be contained. This can be hinted at as well in IDL. > > > > struct SAS_ContextSec{ > > Security::AssociationOptions target_supports; > > Security::AssociationOptions target_requires; > > sequence privilege_authority; > > sequence supported_naming_mechanisms; > > }; > > > > Proposal 2: > > > > We specify a ServiceConfigurationSyntax tag for "none", and > specify that > > the sequence of octet associated with it is empty. > > > > // Corresponding ServiceName for the SCS_None Syntax should be an > empty > > // sequence octets. > > const ServiceConfigurationSyntax SCS_None = -1; > > > > struct SAS_ContextSec{ > > Security::AssociationOptions target_supports; > > Security::AssociationOptions target_requires; > > ServiceConfiguration privilege_authority; > > sequence supported_naming_mechanisms; > > }; > > > > For efficiency I'm in favor of the second approach, because I can > just > > look a the ServiceConfiguration::syntax field and know what to > do. The > > first proposal causes me to look at the length first, index to the > first > > element in the array, and then look at the syntax field. > > The argument for changing target name to singular in a mechanism, is > that a target which supports more than one target name, most likely > does > so because it supports more than 1 authentication mechanim. An > alternate > way to accomplish the same thing would simply be to add another > mechanism definition to its mechanism list. > > If the issue Polar raises is a problem, and I can see how it could > be, > then I would suggest we restrict all the privilege authorities > within a > given mechanism definition to the same type. If we do this, then > there > is another possibility, which will preserve the ability to name > multiple > privilege authorities of the same syntax within a single mechanism. > > That is: > > struct SAS_ContextSec{ > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > ServiceSpecificName > privilege_authority_syntax; > sequence privilege_authorities; > sequence supported_naming_mechanisms; > }; > > We would discard the ServiceConfiguration type. The existing > semantics > of the length of the privilege_authorities sequence being used to > detect > if there are privilege authorities specified would be > maintained. When > the length of the sequnence is 0, the syntax value would be > irrelevant. That approach would imply that the ServiceConfiguration type has more semantics than originally intended, and semantics that are two complex to imply there. I.e. the same type of privilege authority doesn't imply that they have the same naming support. Of course, you can always claim that my comments are contrived, because a server an always be conservative about is mechanism definitions. But for INTEROPERABILITY clients MUST be liberal in what they understand and accept. And this approach of multiplicity for a single mechanism just really complicates matters beyond the task that is necessary. This is the same problem as having several targets in the AS_ContextSec. As Ron points out the solution is just to create a new CSI Mechanism in the list. I say the same consistent approach should be taken here. Singular is much easier to deal with, and you don't have to write alot of text explaining what has to happen. The definition pretty much speaks for itself. I don't know what having multiple privilege authorities in this structure by me except a huge headache in which one I have to choose, prefer, etc. I'd much rather do it with a signular approach. Cheers, -Polar > > As an aside, I also wouldn't mind changing the sequence > > type into a Security::OIDList, but that can be the subject of another > > issue. Also note, to be specific with the document I am pointing to, I > > used the "Security" definitions. Hopefully, we will follow one proposal to > > change the Security::AssociationOptions to CSIIOP::AssociationOptions and > > Security::OID and Security::OIDList to CSI::OID and CSI::OIDList > > respectively. > > > > Cheers, > > -Polar > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Wed, 17 Jan 2001 15:58:00 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: DGZ!!=J#e9$U#!!+4I!! In http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf the relevant (to our discussion) sections which describe the privilege_authorities field are found in paragraphs: [73],[145],[148],[173],[174],[177],[180] the privilege_authorities field of the SAS_ContextSec structure is currently defiend as follows: typedef const short ServiceConfigurationSyntax; const ServiceConfigurationSyntax SCS_GeneralNames = 0; const ServiceConfigurationSyntax SCS_GSSExportedName = 1; typedef sequence ServiceSpecificName; // The name field of the ServiceConfiguration structure identifies a privilege // authority in the format identified in the syntax field. If the syntax is // SCS_GeneralNames, the name field contains an ASN.1 (BER) SEQUENCE // [1..MAX] OF GeneralName, as defined by the type GeneralNames in // [IETF RFC 2459]. If the syntax is SCS_GSSExportedName, the name field // contains a GSS exported name encoded according to the rules in // [IETF RFC 2743] Section 3.2, "Mechanism-Independent Exported Name // Object Format," p. 84. struct ServiceConfiguration { ServiceConfigurationSyntax syntax; ServiceSpecificName name; }; sequence privilege_authorities; the privilege_authorities field can contain 0 or more privilege_authority "configurations" each potentially of different ServiceConfigurationSyntax. Each ServiceConfiguration indicates that the target "supports" authorization tokens of the designated syntax when acquired from the named trusted source. As stated in [177] a target is required to include in its IOR's the names of the privilege_authorities trusted by the target object. The privilege_authorities field (as currently defined) does not indicate that a client is required to provide one or more authorization tokens, nor does it restrict how many of the supported forms from trusted authorities could be included by a client. The issue raised was how does a CSS in its authorization acquistion logic interpret the multi-valued privilege_authorities field. As currently defined, there is no chance for a client to learn what it must do by looking at an IOR, as the IOR is not prescriptive of the client's behavior. The IOR tells the client what it can expect to be accepted by the target. The submission was written with the expectation that it was the client who decided when to acquire and send authorization tokens, how many, of which types, etc. This may be the subject of another issue, but it seems wise to come to a clearer picture of what is currently in the submission. Next - as defined, the privilege_authorities field allows a target to indicate that it supports requests which include multiple authorization tokens acquired from multiple authorities, and thus perhaps of different syntax. In [145], it states that the privilege authority names in the sequence of ServiceConfiguration elements which comprise the privilege_authorities field are arranged in decreasing order of target preference. This statement is the closest thing we provide to telling the client how to select from the multiple values in the privilge authority field (if the client decides to do so). Polar writes: > It is completely hard to determine having multiple privilege authorities > and the names that must be used to assert the identity for the privileges. > In fact, the client may get back an AuthorizationToken that he doesn't > understand, but will need to assert an identity for it's use, quite > possibly with endorsement. Having multiple naming types supported per > privilege authority is fine, but combine that with multiple ones, and you > may get a decision problem for the client. > I think Polar is saying that if the client is being told to acquire privileges form any of N possible authorities, then the name of the identity it must assert along with the acquired authorization token must be selected by the client to match the authorization token. I think he is saying that the dimension of multiple token formats is acceptable if there are not also multiple authorities for each form. Question: Why can't the token acquistion arguments, include in it the identity form that the client intends to use with the token (in its request to the target), such that a properly "bound" authorization token is returned? This is separate from understanding what multiple privilege authorities mean to the client (which we have not clearly defined). It might mean any of the following, and perhaps a few I haven't thought of. 1. get a token from all of them 2. get at most one from each of them 3. get at most one from one of them 4. get exactly one from one of them As the spec is currently written, I think the spec comes closest to expecting behavior 2 of its clients. perhaps what is being advocated is the removal of all such semantics from visibility in the CSIv2 spec, by hiding them in "privilege_authority" blobs (described elsewhere). Or perhaps we are assuming that the semantic we are after is 5. get exactly one using the specified mechanism Ron > It is better to be able to specify a one-to-one correspondence, locking > down the combinations that a server will accept, and the client doesn't > have to do any mucking about deciding what will work. > X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 17 Jan 2001 17:24:30 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Re: Issue: Multiple Privilege Authorities and Supported Naming Types In-Reply-To: <3A660758.24531B92@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 3[*e9"5)e9ZK,!!63:e9 Along with all of this dicussion. The quesion I have to ask is: What exactly does a description of multiple privilege authorities actually buy you over just having one description? (other than complexity). Note, I don't buy arguments for fault tolerance or availablity. Those capabilities should be handled by the semantics of a singlar description, i.e. Fault Tolerant CORBA, DNS bind, WEB, some other protocol, whatever, that comprise the "logical authority". Complicating the Client Security Service to generalize fault tolerance, availability, preference, over a bunch of possibly known, unknown, supported, and unsupported privilege acquisition mechanisms is more than I care to bite off and chew. If there is a GIANT need for "multiple physical authorities", they should be pounded into a single description of a single "logical authority" (or service). Then, the exact semantics of how that space is searched, queried, and the method by which it operates in the face of faults or preference are explicitly relegated to a specification of the "logical authority" and not the Client Security Service specification and implementation. The implemenation of the Client Security Service becomes much simpler to implement and can be much more modular. I know that for a fact. I'm implementing the client side. That's why I raised the issue. -Polar On Wed, 17 Jan 2001, Ron Monzillo wrote: > In http://cgi.omg.org/pub/csiv2-ftf/csiv2-0117011.pdf > > the relevant (to our discussion) sections which describe the > privilege_authorities field are found in paragraphs: > > [73],[145],[148],[173],[174],[177],[180] > > the privilege_authorities field of the SAS_ContextSec structure > is currently defiend as follows: > > typedef const short ServiceConfigurationSyntax; > > const ServiceConfigurationSyntax SCS_GeneralNames = 0; > const ServiceConfigurationSyntax SCS_GSSExportedName = 1; > > typedef sequence ServiceSpecificName; > // The name field of the ServiceConfiguration structure identifies a > privilege > // authority in the format identified in the syntax field. If the > syntax > is > // SCS_GeneralNames, the name field contains an ASN.1 (BER) SEQUENCE > // [1..MAX] OF GeneralName, as defined by the type GeneralNames in > // [IETF RFC 2459]. If the syntax is SCS_GSSExportedName, the name > field > // contains a GSS exported name encoded according to the rules in > // [IETF RFC 2743] Section 3.2, "Mechanism-Independent Exported Name > // Object Format," p. 84. > > struct ServiceConfiguration { > ServiceConfigurationSyntax syntax; > ServiceSpecificName name; > }; > > sequence privilege_authorities; > > the privilege_authorities field can contain 0 or more > privilege_authority "configurations" each potentially of different > ServiceConfigurationSyntax. > Each ServiceConfiguration indicates that the target "supports" > authorization tokens of the designated syntax when acquired from > the named trusted source. > > As stated in [177] a target is required to include in its IOR's > the names of the privilege_authorities trusted by the target > object. > The privilege_authorities field (as currently defined) does not > indicate > that a client is required to provide one or more authorization > tokens, > nor does it restrict how many of the supported forms from trusted > authorities could be included by a client. > > The issue raised was how does a CSS in its authorization acquistion > logic > interpret the multi-valued privilege_authorities field. > > As currently defined, there is no chance for a client to learn what > it > must do by looking at an IOR, as the IOR is not prescriptive of the > client's behavior. The IOR tells the client what it can expect to be > accepted by the target. The submission was written with the > expectation > that it was the client who decided when to acquire and send > authorization tokens, how many, of which types, etc. This may be > the > subject of another issue, but it seems wise to come to a clearer > picture > of what is currently in the submission. > > Next - as defined, the privilege_authorities field allows a target > to > indicate that it supports requests which include multiple > authorization > tokens acquired from multiple authorities, and thus perhaps of > different > syntax. > > In [145], it states that the privilege authority names in the > sequence > of ServiceConfiguration elements which comprise the > privilege_authorities field are arranged in decreasing order of > target > preference. This statement is the closest thing we provide to > telling > the client how to select from the multiple values in the privilge > authority field (if the client decides to do so). > > Polar writes: > > It is completely hard to determine having multiple privilege > authorities > > and the names that must be used to assert the identity for the > privileges. > > In fact, the client may get back an AuthorizationToken that he > doesn't > > understand, but will need to assert an identity for it's use, > quite > > possibly with endorsement. Having multiple naming types supported > per > > privilege authority is fine, but combine that with multiple ones, > and you > > may get a decision problem for the client. > > > I think Polar is saying that if the client is being told to acquire > privileges form any of N possible authorities, then the name of the > identity it must assert along with the acquired authorization token > must be selected by the client to match the authorization token. I > think > he is saying that the dimension of multiple token formats is > acceptable > if there are not also multiple authorities for each form. > > Question: Why can't the token acquistion arguments, include in it > the > identity form that the client intends to use with the token (in its > request to the target), such that a properly "bound" authorization > token > is returned? > > This is separate from understanding what multiple privilege > authorities > mean to the client (which we have not clearly defined). It might > mean > any of the following, and perhaps a few I haven't thought of. > > 1. get a token from all of them > 2. get at most one from each of them > 3. get at most one from one of them > 4. get exactly one from one of them > > As the spec is currently written, I think the spec comes closest to > expecting behavior 2 of its clients. > > perhaps what is being advocated is the removal of all such semantics > from > visibility in the CSIv2 spec, by hiding them in > "privilege_authority" > blobs (described elsewhere). Or perhaps we are assuming that the > semantic > we are after is > > 5. get exactly one using the specified mechanism > > Ron > > > It is better to be able to specify a one-to-one correspondence, > locking > > down the combinations that a server will accept, and the client > doesn't > > have to do any mucking about deciding what will work. > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 18 Jan 2001 03:25:24 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Proprosed Vote Resolution Issue MPASNT Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-427817617-101357569-979806324=:5895" X-UIDL: &:\d9WZ2!!"ABe9l5F!! Attached is a proposed vote resolution for: Issue MPASNT: Multiple Privilege Authorities and Supported Naming Types Basically, elminates much of the complexity by making the privilege_authority field of the SAS_ContextSec singular. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com [] FTF-Issue-MPASNT.html From: "Don Flinn" To: "csiv2-ftf" Cc: "Bob Kukura" Subject: Issues 4200 & 4118 Date: Mon, 12 Mar 2001 12:12:04 -0500 Message-ID: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: mE$e9G- addresses; }; In addition I feel that on the question of multiple privilege authorities, issue 4118, that there should be only one privilege authority. At present there are no implementations that use this field to find a privilege authority. Until we have some experience with using this functionality and understand how it will work in the real world I think that we should keep it simple and just allow one privilege authority name. Don ======================== Down the mid-tier Over the Firewall Nothing but Net ======================== Don Flinn Iona Technologies don.flinn@iona.com Tel: 781-902-8559 FAX: 781-902-8001 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 12 Mar 2001 13:50:35 -0500 (EST) From: Polar Humenn To: Don Flinn cc: csiv2-ftf , Bob Kukura Subject: Re: Issues 4200 & 4118 In-Reply-To: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: TUM!!3(Ie9e,$e9#!g!! On Mon, 12 Mar 2001, Don Flinn wrote: > I would like to propose the following for the SSLIOP module. The use of > multiple Address structures in the sequence addresses would be semantically > equivalent to using multiple mechanisms with one address in each, i.e. a > sequence containing one Address. > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag number > > struct Address { > string host_name; > unsigned short port; > }; > > struct SSLSecTransComponent { > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence
addresses; > }; I still feel that the sequence is unecessary and forboding. However, by bringing multiple addresses up to this level, you are requiring the client security service to multiply the mechanism for each address? So my questions are: What if the length is zero? If length is more than one, is this short hand for multiplying the mechanism in the order of the target security service desired preference? If it is not that way, then that changes quite a bit. > In addition I feel that on the question of multiple privilege authorities, > issue 4118, that there should be only one privilege authority. At present > there are no implementations that use this field to find a privilege > authority. Until we have some experience with using this functionality and > understand how it will work in the real world I think that we should keep it > simple and just allow one privilege authority name. Well, I wouldn't say because we have no experience in this matter. :) It is quite evident in the past that I do not want the client's security service to become a privilege authority service negotiator or a fault management service for any type of privilege authority. The client should do it quickly, get in, get out, by whatever mechanism the service states. If if the privilege service fault tolerant, the ServiceConfiguration should say so. I can not see any notion of having multiple privilege authorities listed for a mechanism, without any semantics defined what it means. In that light, I say that we should deprecate ServiceConfiguationSyntax for GSS_ExportName and DN as well, as they have absolutely no meaning in the specification. Cheers, -Polar > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 12 Mar 2001 14:04:37 -0500 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Flinn CC: csiv2-ftf , Bob Kukura Subject: Re: Issues 4200 & 4118 References: <000001c0ab17$8f5fc670$7485413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _7$"!'k$!!CFa!!@JJe9 Don, We have agreed as part of the resolution of issue 4141/4142 to replace TAG_SSL_SEC_TRANS with TAG_TLS_SEC_TRANS = 36. Among other things this gives us the ability to modify the definition of this component to handle problems like that presented by issue 4200. A similar change will also be necessary to the SECIOP transport component. I'll have a modified document out either today, or tomorrow to help us keep track of what we've done so far. Linda passed Juergen the Published Spec last fri. and he will be giving us a pointer to it on the OMG site some time soon. I am merging the issue resolutions on top of that doc (which is csiv2-011701 + a title page inserted by Linda). Ron Don Flinn wrote: > > I would like to propose the following for the SSLIOP module. The use of > multiple Address structures in the sequence addresses would be semantically > equivalent to using multiple mechanisms with one address in each, i.e. a > sequence containing one Address. > > const IOP::ComponentId TAG_SSL_SEC_TRANS = 21; // New tag number > > struct Address { > string host_name; > unsigned short port; > }; > > struct SSLSecTransComponent { > Security::AssociationOptions target_supports; > Security::AssociationOptions target_requires; > sequence
addresses; > }; > > In addition I feel that on the question of multiple privilege authorities, > issue 4118, that there should be only one privilege authority. At present > there are no implementations that use this field to find a privilege > authority. Until we have some experience with using this functionality and > understand how it will work in the real world I think that we should keep it > simple and just allow one privilege authority name. > > Don > > ======================== > Down the mid-tier > Over the Firewall > Nothing but Net > ======================== > > Don Flinn > Iona Technologies > don.flinn@iona.com > Tel: 781-902-8559 > FAX: 781-902-8001 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 14 Mar 2001 13:42:14 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Issue 4118 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: *P`!!W5ad9 X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Re: Issue 4118 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=koi8-r X-UIDL: *Hfd9R;,!!d''!!+;k!! I can't say that I agree with all Polar's points but I can see it clearly that there is no consensus in the FTF on this issue resolution. Therefore, I suggest that the FTF leaves this issue unresolved. Maybe it's not the best way to solve the issue generally but it looks to me as the most acceptable one today taking into account the lack of agreement. Konstantin Polar Humenn wrote: > Points I would like to make in favor of one privilege authority is client > code foot print, and future revisions of the CSIv2 specification. > > If there is only one privilege_authority in the security mechanism the > client looks at the Service Configuration Syntax tag specification and > decides whether it can deal with it. Perhaps the CSS has a module plug-in > for dealing with that type of privilege authority. IMHO, modularization is > a GOOD THING! > > Multiple privilege authorities are not as simple as Ron thinks. A couple > of weeks ago, he explained it as getting a AuthorizationToken from just > any one of them. Today, it was now getting an AuthorizationElement (not an > AuthorizationToken) from each of them. > > A type of a privilege authority "service" can be something specified in > the IOR to handle several things, whether that be CORBA, some IETF ASN.1 > protocol, or multiple "privilege authority" sources with semantics of > redundancy, additive, fail over, fault tolerant, default, etc). [my point > here is that the issue of multiple privilege authorities for a security > mechanism is not a simple one]. > > By putting multiple privilege authorities in the security mechanism you > are forcing the client to *always* have code to deal with multiple > privileges authorities, even though the client may ever only ever expect > to deal with just one authority. Multiple privilege authority > specification causes client code to be bloated with unnecessary > functionality. IMHO, this is a BAD thing!! > > By having a single privilege authority, the client need only include code > for the types of privilege authority services he expects. IMHO, this is a > GOOD thing! > > With multiple privilege authorities, if the functionality changes (i.e. > Ron didn't get it right the first time), then the entire CSIv2 > specification has to be revised! IMHO, this is a BAD thing! > > Subsequently, if the spec has to be revised then all the implementations of > a CSIv2 CSS out there have to be changed and probably remain backwards > compatible as well. IMHO, that is a BAD thing!! > > If the specification of the privilege authority is singular, then if you > want a specification for multiple privilege authorities, specify one with > a new RFP, with complete specification of the semantics of what needs to > be done on the client side. The CSIv2 specification DOES NOT have to be > touched! IMHO, this is a GOOD THING!! > > With the singular approach, if the functionality of privilege authority > service that contains multiple privileges authority sources needs to be > revised then, ONLY the document that specifies its functionality needs to > be revised, and the CSIv2 specification DOES NOT have to be touched! IMHO, > this is a GOOD THING. > > With the multiple privilege authority approach, the client code is going > to have to deal with *ALL* types of privilege authorities > (protocols,privilege semantics, etc.) in a general manner. I feel that > this cannot be done with out a lengthly specification, too long for this > document. IMHO, this is a BAD thing! > > Furthermore, I think that functionality goes beyond that of this FTF. This > is a BAD Thing! > > So, the bottom line is I came up with this score sheet: > > Singular Multiple > Reasons > > Good 4 0 > > Bad 0 5 > > I think that is enough to warrant changing the specification in this FTF > to a singluar privilege authority. > > Cheers, > -Polar > > ------------------------------------------------------------------- > Polar Humenn Adiron, LLC > mailto:polar@adiron.com 2-212 CST > Phone: 315-443-3171 Syracuse, NY 13244-4100 > Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 15 Mar 2001 10:21:45 -0500 (EST) From: Polar Humenn To: Konstantin Beznosov cc: csiv2-ftf@omg.org Subject: Re: Issue 4118 In-Reply-To: <3AB0D64F.44DBDE8@concept5.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: K"fd9SMj!!_ I can't say that I agree with all Polar's points but I can see it clearly that > there is no consensus in the FTF on this issue resolution. Therefore, I suggest > that the FTF leaves this issue unresolved. Maybe it's not the best way to solve > the issue generally but it looks to me as the most acceptable one today taking > into account the lack of agreement. Hmmm. What does this mean? First of all, it is an issue, and it cannot go "unresolved". All issues must be addressed. Second of all, it is pretty presumptous that you are sole judge whether there is consensus amongst all members of the FTF. What I would like to see is to have this FTF move faster than a slow boat to China. Let's put up resolutions and let the constituents vote, and let the powers that be veto if they wish. Jishnu has scheduled votes for the Core RTF without even knowing what the resolutions will be. That mandates progress. What do we do? We sit around pussy footing around talking over and under issues into cyber dust bin, just so we can yell at each other on the phone on the next wednesday without any results. That is, by god, if anybody even shows up to it. And then somehow we have to wait for everybody to "feel good" before a vote slips out onto the table. Since we been moving so slow to date, whether this is a intentional tactic or not, we are now relagated to poor and non-optimal solutions in the CSIv2 protocol and its implied implementations merely by the sole reason of being locked in my Sun's, and as far as I have heard, only Sun's implementation schedules and their threatening veto power. I'm not blaming Sun for having a weighty inflexible implemetation squad since they have to carry the EJB anchor, but if we move swiftly with mandated progress, we could have avoided this unfortunate situation. Let's get moving! -Polar > > Konstantin > > Polar Humenn wrote: > > > Points I would like to make in favor of one privilege authority is > client > > code foot print, and future revisions of the CSIv2 specification. > > > > If there is only one privilege_authority in the security mechanism > the > > client looks at the Service Configuration Syntax tag specification > and > > decides whether it can deal with it. Perhaps the CSS has a module > plug-in > > for dealing with that type of privilege authority. IMHO, > modularization is > > a GOOD THING! > > > > Multiple privilege authorities are not as simple as Ron thinks. A > couple > > of weeks ago, he explained it as getting a AuthorizationToken from > just > > any one of them. Today, it was now getting an AuthorizationElement > (not an > > AuthorizationToken) from each of them. > > > > A type of a privilege authority "service" can be something > specified in > > the IOR to handle several things, whether that be CORBA, some IETF > ASN.1 > > protocol, or multiple "privilege authority" sources with semantics > of > > redundancy, additive, fail over, fault tolerant, default, > etc). [my point > > here is that the issue of multiple privilege authorities for a > security > > mechanism is not a simple one]. > > > > By putting multiple privilege authorities in the security > mechanism you > > are forcing the client to *always* have code to deal with multiple > > privileges authorities, even though the client may ever only ever > expect > > to deal with just one authority. Multiple privilege authority > > specification causes client code to be bloated with unnecessary > > functionality. IMHO, this is a BAD thing!! > > > > By having a single privilege authority, the client need only > include code > > for the types of privilege authority services he expects. IMHO, > this is a > > GOOD thing! > > > > With multiple privilege authorities, if the functionality changes > (i.e. > > Ron didn't get it right the first time), then the entire CSIv2 > > specification has to be revised! IMHO, this is a BAD thing! > > > > Subsequently, if the spec has to be revised then all the > implementations of > > a CSIv2 CSS out there have to be changed and probably remain > backwards > > compatible as well. IMHO, that is a BAD thing!! > > > > If the specification of the privilege authority is singular, then > if you > > want a specification for multiple privilege authorities, specify > one with > > a new RFP, with complete specification of the semantics of what > needs to > > be done on the client side. The CSIv2 specification DOES NOT have > to be > > touched! IMHO, this is a GOOD THING!! > > > > With the singular approach, if the functionality of privilege > authority > > service that contains multiple privileges authority sources needs > to be > > revised then, ONLY the document that specifies its functionality > needs to > > be revised, and the CSIv2 specification DOES NOT have to be > touched! IMHO, > > this is a GOOD THING. > > > > With the multiple privilege authority approach, the client code is > going > > to have to deal with *ALL* types of privilege authorities > > (protocols,privilege semantics, etc.) in a general manner. I feel > that > > this cannot be done with out a lengthly specification, too long > for this > > document. IMHO, this is a BAD thing! > > > > Furthermore, I think that functionality goes beyond that of this > FTF. This > > is a BAD Thing! > > > > So, the bottom line is I came up with this score sheet: > > > > Singular Multiple > > Reasons > > > > Good 4 0 > > > > Bad 0 5 > > > > I think that is enough to warrant changing the specification in > this FTF > > to a singluar privilege authority. > > > > Cheers, > > -Polar > > > > > ------------------------------------------------------------------- > > Polar Humenn Adiron, LLC > > mailto:polar@adiron.com 2-212 CST > > Phone: 315-443-3171 Syracuse, NY 13244-4100 > > Fax: 315-443-4745 http://www.adiron.com > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Sender: Peter.Walker@Sun.COM Message-ID: <3AB0E35A.E4475838@eng.Sun.COM> Date: Thu, 15 Mar 2001 07:44:26 -0800 From: peter walker Organization: Sun Microsystems X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Konstantin Beznosov , csiv2-ftf@omg.org Subject: Re: Issue 4118 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3b7!!+)[!!jJ$!!B4Qe9 Polar Humenn wrote: Well, since we got a mention..... > > On Thu, 15 Mar 2001, Konstantin Beznosov wrote: > > > I can't say that I agree with all Polar's points but I can see it > clearly that > > there is no consensus in the FTF on this issue > resolution. Therefore, I suggest > > that the FTF leaves this issue unresolved. Maybe it's not the best > way to solve > > the issue generally but it looks to me as the most acceptable one > today taking > > into account the lack of agreement. > > Hmmm. What does this mean? > > First of all, it is an issue, and it cannot go "unresolved". The FTF can indeed decide to defer an issue. It can even advise that a particular issue is big enough to warrant a new RFP. > All issues > must be addressed. Second of all, it is pretty presumptous that you > are > sole judge whether there is consensus amongst all members of the > FTF. I believe each member is free to share their thoughts. I assumed that Konstantin was expressing his opinion. > > What I would like to see is to have this FTF move faster than a slow > boat > to China. Let's put up resolutions and let the constituents vote, > and let > the powers that be veto if they wish. Jishnu has scheduled votes for > the > Core RTF without even knowing what the resolutions will be. That > mandates progress. > > What do we do? We sit around pussy footing around talking over and > under > issues into cyber dust bin, just so we can yell at each other on the > phone > on the next wednesday without any results. That is, by god, if > anybody > even shows up to it. And then somehow we have to wait for everybody > to > "feel good" before a vote slips out onto the table. > > Since we been moving so slow to date, whether this is a intentional > tactic > or not, we are now relagated to poor and non-optimal solutions in > the > CSIv2 protocol and its implied implementations merely by the sole > reason > of being locked in my Sun's, and as far as I have heard, only Sun's > implementation schedules and their threatening veto power. Certainly we are not the only company implementing this spec. Yes there are some key aspects of the spec that we would not like to see become unstable in the FTF process. We are referencing the specification for J2EE and we believe we have a responsibility to the whole Enterprise Java community to ensure that the FTF completes its task in a timely manner. > > I'm not blaming Sun for having a weighty inflexible implemetation > squad > since they have to carry the EJB anchor, Please visit http://java.sun.com/j2ee/compatibility.html to see how many other companies also have "squads" who also believe that a timely resolution in the FTF is a good thing. Peter. -- ================================================================== Peter J. Walker Sun Microsystems, Inc. Manager, J2EE Architecture, Enterprise Java. Software Systems Group. Cupertino, CA. mailto:pwalker@eng.Sun.com http://java.sun.com/j2ee (408)517-5679 ================================================================== X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Thu, 15 Mar 2001 10:58:20 -0500 (EST) From: Polar Humenn To: peter walker cc: Konstantin Beznosov , csiv2-ftf@omg.org Subject: Re: Issue 4118 In-Reply-To: <3AB0E35A.E4475838@eng.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: +7ed9%#C!!R9Td9?VYd9 On Thu, 15 Mar 2001, peter walker wrote: > Certainly we are not the only company implementing this spec. Yes there > are some key aspects of the spec that we would not like to see become > unstable in the FTF process. Please kindly specify exactly these key aspects that you want protected, so that we are not shooting in the dark. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 20 Mar 2001 14:42:19 -0500 (EST) From: Polar Humenn To: Ron Monzillo cc: csiv2-ftf@omg.org Subject: Issue 4118 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: N-+e9Sn&!!OO"!!m94!! Comments and suggestions on Sun's proposal for Issue 4118. You can obviously note that I do not agree with the proposed change, which is footnoting that at some later date this specification may address this issue. That is not a good answer, and it doesn't solve any problems. The goal for this FTF should be that specification not to have to change in the future. It should be of such quality, and well designed and written so that no change in the future is needed. A singular privilege_authority service specification will make chaning the specification at later date a moot point, and the solution will be quite modular, for all the reasons I mentioned in my letter last week. I'll repost it. I suggest that we take all proprosed resolutions to this issue and put it to a vote. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 20 Mar 2001 14:44:33 -0500 (EST) From: Polar Humenn To: csiv2-ftf@omg.org Subject: Issue 4118 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 54C!!/Yg!!P,Le9mgC!! Repost: Points I would like to make in favor of one privilege authority is client code foot print, and future revisions of the CSIv2 specification. If there is only one privilege_authority in the security mechanism the client looks at the Service Configuration Syntax tag specification and decides whether it can deal with it. Perhaps the CSS has a module plug-in for dealing with that type of privilege authority. IMHO, modularization is a GOOD THING! Multiple privilege authorities are not as simple as Ron thinks. A couple of weeks ago, he explained it as getting a AuthorizationToken from just any one of them. Today, it was now getting an AuthorizationElement (not an AuthorizationToken) from each of them. A type of a privilege authority "service" can be something specified in the IOR to handle several things, whether that be CORBA, some IETF ASN.1 protocol, or multiple "privilege authority" sources with semantics of redundancy, additive, fail over, fault tolerant, default, etc). [my point here is that the issue of multiple privilege authorities for a security mechanism is not a simple one]. By putting multiple privilege authorities in the security mechanism you are forcing the client to *always* have code to deal with multiple privileges authorities, even though the client may ever only ever expect to deal with just one authority. Multiple privilege authority specification causes client code to be bloated with unnecessary functionality. IMHO, this is a BAD thing!! By having a single privilege authority, the client need only include code for the types of privilege authority services he expects. IMHO, this is a GOOD thing! With multiple privilege authorities, if the functionality changes (i.e. Ron didn't get it right the first time), then the entire CSIv2 specification has to be revised! IMHO, this is a BAD thing! Subsequently, if the spec has to be revised then all the implementations of a CSIv2 CSS out there have to be changed and probably remain backwards compatible as well. IMHO, that is a BAD thing!! If the specification of the privilege authority is singular, then if you want a specification for multiple privilege authorities, specify one with a new RFP, with complete specification of the semantics of what needs to be done on the client side. The CSIv2 specification DOES NOT have to be touched! IMHO, this is a GOOD THING!! With the singular approach, if the functionality of privilege authority service that contains multiple privileges authority sources needs to be revised then, ONLY the document that specifies its functionality needs to be revised, and the CSIv2 specification DOES NOT have to be touched! IMHO, this is a GOOD THING. With the multiple privilege authority approach, the client code is going to have to deal with *ALL* types of privilege authorities (protocols,privilege semantics, etc.) in a general manner. I feel that this cannot be done with out a lengthly specification, too long for this document. IMHO, this is a BAD thing! Furthermore, I think that functionality goes beyond that of this FTF. This is a BAD Thing! So, the bottom line is I came up with this score sheet: Singular Multiple Reasons Good 4 0 Bad 0 5 I think that is enough to warrant changing the specification in this FTF to a singluar privilege authority. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 3 Apr 2001 13:27:41 -0400 (EDT) From: Polar Humenn To: Don Flinn cc: csiv2-ftf Subject: Issue 4118: (was: Outstanding Issues) In-Reply-To: <001001c0bb2e$c6c98840$2302a8c0@boston.amer.iona.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: F$pd9P:3!!Q%~!!VjP!! Greetings, I'm just focusing on Issue 4118 here in Don's message. On Mon, 2 Apr 2001, Don Flinn wrote: > Hi All > > We have seven outstanding issues for the CSIv2 FTF. Of these Polar >and Ron > are in agreement on three and have a disagreement on four. > 4118 Multiple Privilege Authorities and Supported Naming Types > Disagreement: > Ron: Retain a sequence of Privilege Authorities and if more than one > Privilege is passed in the sequence all but the first in > undefined. The > syntax field is used to identify the form of the name. > Polar: Only allow one Privilege Authority. The semantics of > multiple > privilege authorities are not defined. > My reading of the issue: The client may have a decision problem if > it is > sent multiple privilege authorities. Don's reading of the issue is correct. The Client has no idea what to do with multiple privilege authorities, nor is there any attempt to define what it means, especially without getting into RFP territory. I don't want to see it go blatantly undefined, as that's not what the "Finalization" task force is about. Let's "finalize" this protocol. The really elegant solution to the problem is to make it one singular privilege "service". If there are actually multiple authorities within that service, then they should be defined within that "service" description, which describes the semantics of how to deal multiple privilege authorities. That can be the subject of an RFP down the line, once people get experience with the need for such things. Furthermore, on a new point, I would like to see the definition of a privilege service field, i.e. the "ServiceConfiguration" type, be changed to an IOP::TaggedComponent. If we take this approach, then when there are new IOP tags allocated for particular privilege services, they can be registered with the OMG in a common place with a pointer to the specification with the definition of the corresponding encoding. Right now, these ServiceConfigurationSyntax tags would have to be registered in other specs, which means that the tags could possibly end up all over the place, or that the CSIv2 spec needs to be revised, i.e. if an RFP explicitly has to register a new tag is CSIv2). I don't like that idea. It complicates specification management. Also, the OMG doesn't need another tag space to keep track of for extensible features. The IOP tag space is sufficient. Jishnu, is this an acceptable approach for registration of such things? So, how about it folks? Change the definition of privilege_authorities to a singular one, i.e. privilege_service, and change it's definition to an IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the absence of a privilege_service. Cheers, -Polar Reply-To: "David Chizmadia" From: "David Chizmadia" To: "csiv2-ftf" References: Subject: Re: Issue 4118: (was: Outstanding Issues) Date: Tue, 3 Apr 2001 14:07:57 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: X9bd9ENBe9p0S!!#m\!! I'd like to add at least one voice to Polar's that we SHOULD NOT adopt unspecified (or underspecified) functionality "just because". While promia is moving into a product space where protocol-level exploits are what will sell our product, I REALLY hate the idea of knowingly specifying an incomplete protocol. (I grew up in the assurance community and the first thing I learned is that assurance is screwed when your specification is imprecise!!) My concern is that the protocol could potentially be used in unusual and nasty ways when those unspecified "features" are used for proprietary extensions to a poorly implemented product and thereby become a path into that product. Since the product is poorly implemented because it HAD to get to market first, we can be sure that enough people will use it to make the inevitable exploits a serious security annoyance. Then again, if CSIv2 becomes the success that we all hope, remember that Microsoft might end up having to appear to support it. Any un(der)specified aspect of the protocol will represent a sublime opportunity for M$ to adopt and break the protocol. To recap, I agree with Polar that the protocol should only support a single Privilege Authority, which authority could allow runtime federation with other authorities "under-the-covers". On the issue of changing the "ServiceConfiguration" type, to an IOP::TaggedComponent to allow more modular management of its evolution, I agree with Polar - subject to the absence of a convincing argument that such an approach would impede interoperability in any way. -DMC David Chizmadia Senior Software Security Architect Promia, Inc dchizmadia@promia.com ----- Original Message ----- From: "Polar Humenn" To: "Don Flinn" Cc: "csiv2-ftf" Sent: Tuesday, April 03, 2001 1:27 PM Subject: Issue 4118: (was: Outstanding Issues) > > Greetings, > > I'm just focusing on Issue 4118 here in Don's message. > > On Mon, 2 Apr 2001, Don Flinn wrote: > > > Hi All > > > > We have seven outstanding issues for the CSIv2 FTF. Of these >Polar and Ron > > are in agreement on three and have a disagreement on four. > > > > > 4118 Multiple Privilege Authorities and Supported Naming Types > > Disagreement: > > Ron: Retain a sequence of Privilege Authorities and if more than >one > > Privilege is passed in the sequence all but the first in >undefined. The > > syntax field is used to identify the form of the name. > > Polar: Only allow one Privilege Authority. The semantics of >multiple > > privilege authorities are not defined. > > My reading of the issue: The client may have a decision problem if >it is > > sent multiple privilege authorities. > > Don's reading of the issue is correct. The Client has no idea what >to do > with multiple privilege authorities, nor is there any attempt to >define > what it means, especially without getting into RFP territory. > > I don't want to see it go blatantly undefined, as that's not what >the > "Finalization" task force is about. Let's "finalize" this protocol. > > The really elegant solution to the problem is to make it one >singular > privilege "service". If there are actually multiple authorities >within > that service, then they should be defined within that "service" > description, which describes the semantics of how to deal multiple > privilege authorities. That can be the subject of an RFP down the >line, > once people get experience with the need for such things. > > Furthermore, on a new point, I would like to see the definition of a > privilege service field, i.e. the "ServiceConfiguration" type, be >changed > to an IOP::TaggedComponent. > > If we take this approach, then when there are new IOP tags allocated >for > particular privilege services, they can be registered with the OMG >in a > common place with a pointer to the specification with the definition >of > the corresponding encoding. > > Right now, these ServiceConfigurationSyntax tags would have to be > registered in other specs, which means that the tags could possibly >end up > all over the place, or that the CSIv2 spec needs to be revised, >i.e. if an > RFP explicitly has to register a new tag is CSIv2). I don't like >that idea. > It complicates specification management. Also, the OMG doesn't need > another tag space to keep track of for extensible features. The IOP >tag > space is sufficient. > > Jishnu, is this an acceptable approach for registration of such >things? > > So, how about it folks? Change the definition of >privilege_authorities to a > singular one, i.e. privilege_service, and change it's definition to >an > IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the >absence of > a privilege_service. > > Cheers, > -Polar > > Date: Tue, 03 Apr 2001 14:34:28 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Don Flinn , csiv2-ftf Subject: Re: Issue 4118: (was: Outstanding Issues) References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: j?"!!`3Yd9Y1Le9MMF!! Polar Humenn wrote: > > Greetings, > > I'm just focusing on Issue 4118 here in Don's message. > > On Mon, 2 Apr 2001, Don Flinn wrote: > > > Hi All > > > > We have seven outstanding issues for the CSIv2 FTF. Of these Polar and Ron > > are in agreement on three and have a disagreement on four. > > > > > 4118 Multiple Privilege Authorities and Supported Naming Types > > Disagreement: > > Ron: Retain a sequence of Privilege Authorities and if more than one > > Privilege is passed in the sequence all but the first in undefined. The > > syntax field is used to identify the form of the name. > > Polar: Only allow one Privilege Authority. The semantics of multiple > > privilege authorities are not defined. > > My reading of the issue: The client may have a decision problem if it is > > sent multiple privilege authorities. > > Don's reading of the issue is correct. The Client has no idea what to do > with multiple privilege authorities, nor is there any attempt to define > what it means, especially without getting into RFP territory. > > I don't want to see it go blatantly undefined, as that's not what the > "Finalization" task force is about. Let's "finalize" this protocol. Actually, I don't take that extreme position. It is perfectly legitimate for an FTF to say that only this part of the behavior is defined (i.e. the first privilege authority part) and behavior when additional privilege authorities are found is that they are ignored, until additional standardization takes place to define specific behavior in that area. I tend to agree with Ron that we should avoid changing (relatively harmless) data structures at this point, and that leave open possibilities of further refinement of behavior in additional RFPs. > The really elegant solution to the problem is to make it one singular > privilege "service". If there are actually multiple authorities within > that service, then they should be defined within that "service" > description, which describes the semantics of how to deal multiple > privilege authorities. That can be the subject of an RFP down the line, > once people get experience with the need for such things. Perhaps. But this seems like designing additional features on the fly under the hood of the FTF to me. If said RFP is issued it can just as well use the existing structure and bestow additional meaning to the contents in a backward compatible manner. Also, if these sorts of changes create a jeopardy for the inclusion of this standard by reference in the J2EE specification, that would be entirely unacceptable as far as we are concerned. > Furthermore, on a new point, I would like to see the definition of a > privilege service field, i.e. the "ServiceConfiguration" type, be > changed > to an IOP::TaggedComponent. Seems like a rather significant change of dubious value to me. > If we take this approach, then when there are new IOP tags allocated for > particular privilege services, they can be registered with the OMG in a > common place with a pointer to the specification with the definition of > the corresponding encoding. So now we will land up with a slew of IOP Component Tags for instances of Privilege Services. Why is this better than just managing allocation of constants of type ServiceContextSyntax is not clear to me. Yeah they will need to be registered and maintained but so what? Yet another set of constants to register and maintain, but they are localized to the CSIv2 protocol usage, as opposed to modifying GIOP/IIOP, which in effect is what addition of new IOP component tags involves. > Right now, these ServiceConfigurationSyntax tags would have to be > registered in other specs, which means that the tags could possibly > end up > all over the place, or that the CSIv2 spec needs to be revised, > i.e. if an > RFP explicitly has to register a new tag is CSIv2). I don't like > that idea. But you like the idea that the Core GIOP/IIOP chapter would need to be revised instead. Hmmmm..... > It complicates specification management. Also, the OMG doesn't need > another tag space to keep track of for extensible features. The IOP > tag > space is sufficient. I don't agree that this would be an appropriate use of IOP Component Tags, even if it saves OMG some administrivia. CSIv2 related allocation of constant values are best kept localized to CSIv2, and not spread out into GIOP/IIOP specification, IMHO, thus saving the poor sod in embedded systems who happens to just use GIOP from having to aorry about additional standard IOP TAGs etc. > Jishnu, is this an acceptable approach for registration of such things? > > So, how about it folks? Change the definition of privilege_authorities to a > singular one, i.e. privilege_service, and change it's definition to an > IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the absence of > a privilege_service. Seems like a gratuitious change that does not particularly fix any problem that cannot be fixed less obtrusively in other ways, to me. We would tend to vote against these proposed changes.:-] OK, now I have put my chain mail on and will remain off line for the next four days.:-) Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 3 Apr 2001 15:47:05 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Don Flinn , csiv2-ftf Subject: Re: Issue 4118: (was: Outstanding Issues) In-Reply-To: <3ACA17B4.298D5362@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: ki@!!gl_!!M;,e92NE!! Comments below. -Polar On Tue, 3 Apr 2001, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > Greetings, > > > > I'm just focusing on Issue 4118 here in Don's message. > > > > On Mon, 2 Apr 2001, Don Flinn wrote: > > > > > Hi All > > > > > > We have seven outstanding issues for the CSIv2 FTF. Of these Polar and Ron > > > are in agreement on three and have a disagreement on four. > > > > > > > > > 4118 Multiple Privilege Authorities and Supported Naming Types > > > Disagreement: > > > Ron: Retain a sequence of Privilege Authorities and if more than one > > > Privilege is passed in the sequence all but the first in undefined. The > > > syntax field is used to identify the form of the name. > > > Polar: Only allow one Privilege Authority. The semantics of multiple > > > privilege authorities are not defined. > > > My reading of the issue: The client may have a decision problem if it is > > > sent multiple privilege authorities. > > > > Don's reading of the issue is correct. The Client has no idea what to do > > with multiple privilege authorities, nor is there any attempt to define > > what it means, especially without getting into RFP territory. > > > > I don't want to see it go blatantly undefined, as that's not what the > > "Finalization" task force is about. Let's "finalize" this protocol. > > Actually, I don't take that extreme position. It is perfectly legitimate > for an FTF to say that only this part of the behavior is defined (i.e. > the first privilege authority part) and behavior when additional > privilege authorities are found is that they are ignored, until > additional standardization takes place to define specific behavior in > that area. I tend to agree with Ron that we should avoid changing > (relatively harmless) data structures at this point, and that leave open > possibilities of further refinement of behavior in additional RFPs. It may be perfectly legitimate for an FTF to do NOTHING, but I wouldn't say that position, in this case, serves any good technical merit, or progress toward issue resolution. I disagree that it is a "harmless" data structure. It does cause harm in its underspecification, and furthermore, I don't think that multiple "privilege authorities" is a factet that is going to be realized anytime soon. And if it does it will have a whole bunch of quilted patchwork restrictions, such as if you have P1,P2,P3, none of P can be of type T, with and if one P is of type S, then it takes precedence one over type V, and furthermore, if one of Type C is in there, then there cannot be any others, and you have to call type C over and over again until you get a response. Blech! Uggggghh! Garbage! Spec Pollution. > > The really elegant solution to the problem is to make it one singular > > privilege "service". If there are actually multiple authorities within > > that service, then they should be defined within that "service" > > description, which describes the semantics of how to deal multiple > > privilege authorities. That can be the subject of an RFP down the line, > > once people get experience with the need for such things. > > Perhaps. But this seems like designing additional features on the fly > under the hood of the FTF to me. There is nothing going on under the hood of this FTF! It is not designing "additional" features. There is nothing in the protocol supporting or defining the semantics for multiple privilege authorities. So, I'm just trying to call a SPADE a SPADE. The functionality isn't there so remove the potential of abuse and definite incompatibilities down the line, and give it a DEFINITE UNAMBIGOUS Semantics. > If said RFP is issued it can just as well use the existing structure > and bestow additional meaning to the contents in a backward > compatible > manner. That means the CSIv2 spec and semantics have to be revised needlessly, and possibly endlessly. And I SEVERELY doubt that you can provide backwards compatibility based on the "quilted patchwork" of restrictions that I presented above, which would arrise out of doing so. > Also, if these sorts of changes create a jeopardy for the inclusion of > this standard by reference in the J2EE specification, that would be > entirely unacceptable as far as we are concerned. I honestly do believe that there are people at Sun who do see technical merit in this solution. ;^} > > Furthermore, on a new point, I would like to see the definition of a > > privilege service field, i.e. the "ServiceConfiguration" type, be changed > > to an IOP::TaggedComponent. > > Seems like a rather significant change of dubious value to me. > > > If we take this approach, then when there are new IOP tags allocated for > > particular privilege services, they can be registered with the OMG in a > > common place with a pointer to the specification with the definition of > > the corresponding encoding. > > So now we will land up with a slew of IOP Component Tags for instances > of Privilege Services. Why is this better than just managing allocation > of constants of type ServiceContextSyntax is not clear to me. Yeah they > will need to be registered and maintained but so what? Yet another set > of constants to register and maintain, but they are localized to the > CSIv2 protocol usage, as opposed to modifying GIOP/IIOP, which in effect > is what addition of new IOP component tags involves. I was only asking your sage advice on whether it was a good approach or not, given the way things are currently managed. I surmise that you think it is not. So be it. I thought it simply would be simpler to have these tags residing in a strongly adopted, well known, and sacrosanct registry. Furthermore, I believe that CSIv2 is a part of the whole GIOP/IIOP story and in addition any new standard privilege services that are specified are a part of that version of IIOP. Wouldn't you agree? > > Right now, these ServiceConfigurationSyntax tags would have to be > > registered in other specs, which means that the tags could > > possibly end up > > all over the place, or that the CSIv2 spec needs to be revised, > > i.e. if an > > RFP explicitly has to register a new tag is CSIv2). I don't like > > that idea. > > But you like the idea that the Core GIOP/IIOP chapter would need to > > be > revised instead. Hmmmm..... Like I said, CSIv2 is a part of GIOP/IIOP. > > It complicates specification management. Also, the OMG doesn't need > > another tag space to keep track of for extensible features. The IOP tag > > space is sufficient. > > I don't agree that this would be an appropriate use of IOP Component > Tags, even if it saves OMG some administrivia. CSIv2 related allocation > of constant values are best kept localized to CSIv2, and not spread out > into GIOP/IIOP specification, IMHO, thus saving the poor sod in embedded > systems who happens to just use GIOP from having to aorry about > additional standard IOP TAGs etc. Well, what is he worrying about those tags when they do not apply to his application? If that is indeed the case, then he must still worry about TAG_SECIOP_INET_SEC_TRANS, TAG_GENERIC_SEC_MECH, TAG_ASSOCIATION_OPTIONS, TAG_SEC_NAME, TAG_SPKM_1_SEC_MECH, TAG_SPKM_2_SEC_MECH, TAG_KerberosV5_SEC_MECH, TAG_CSI_ECMA_Secret_SEC_MECH, TAG_CSI_ECMA_Hybrid_SEC_MECH, TAG_CSI_ECMA_Public_SEC_MECH, TAG_SSL_SEC_TRANS, TAG_TLS_SEC_TRANS, TAG_SECIOP_SEC_TRANS, TAG_NULL_TAG, TAG_CSI_SEC_MECH_LIST, of which the latter 4 are introduced by CSIv2. > > Jishnu, is this an acceptable approach for registration of such things? > > > > So, how about it folks? Change the definition of privilege_authorities to a > > singular one, i.e. privilege_service, and change it's definition to an > > IOP::TaggedComponent. We can use the IOP::TAG_NULL_TAG for the absence of > > a privilege_service. > > Seems like a gratuitious change that does not particularly fix any > problem that cannot be fixed less obtrusively in other ways, to me. > > We would tend to vote against these proposed changes.:-] > > OK, now I have put my chain mail on and will remain off line for the > next four days.:-) Have fun. Cheers, -Polar > Jishnu. > Date: Wed, 11 Apr 2001 17:20:09 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Proposed resolution to issue 4118: Multiple Privilege Authorities and Supported Naming Types Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: `~n!!T> X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: csiv2-ftf@omg.org Subject: Proposed resolution to issue 4118: Multiple Privilege Authorities and Supported Naming Types Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: `~n!!T> To: Ron Monzillo cc: Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authorities and Supported Naming Types In-Reply-To: <3AD4CA89.BA0FA9F8@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by emerald.omg.org id f3C0QTv09775 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: (a6!!Q$Zd9>Tl!!6nB!! Hi, I do not agree with some of the text below. On Wed, 11 Apr 2001, Ron Monzillo wrote: > Issue 4118: Multiple Privilege Authorities and Supported Naming Types > > base document: > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > This issue argues that the specification of multiple privilege > authorities in a target IOR unnecessarily complicate> authorization token acquisition logic, especially as the semantics of > multiple privilege authorities are not completely defined. > > Proposed Resolution: > > [1] replace paragraph 148 with the following paragraph > > The privilege_authorities field contains a list of the names of 0 or > more privilege authorities. A non-empty list indicates that the target > supports authorization tokens provided by a CSS (in EstablishContext > messages) and containing AuthorizationElements from the authority named > by the first ServiceConfiguration element in the list. If the > privilege_authorities field contains more than one ServiceConfiguration > element, A CSS shall be conformant if it ignores all > ServiceConfiguration elements beyond the first. The syntax field within > the ServiceConfiguration element identifies the format used to represent > the authority. Two alternative formats are currently defined: an ASN.1 > encoding of the GeneralNames (as defined in [IETF RFC 2459]) which > identify a privilege authority, or a GSS exported name (as defined in > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > authority. Why don't I take a crack at it? My main beef with this is talking about conformance of CSSs in this part of the spec. Let's talk about the protocol. The privilege_authorities field contains a sequence of at most one ServiceConfiguration. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. The syntax field .... There really isn't any need to say anything else. Proprietary extensions are proprietary extensions, so what? So, if we are going to go this way, I see no reason to call out anything beyond "contains at most one" element. In fact, if you were to call out anything at all, then I suggest this: "If the CSS encounters a security mechanism with more than one ServiceConfiguration in the privilege_authorities field, the security mechanism shall be ignored as if it did not exist." But I don't even think that really needs to be called out, does it? I guess I am not in favor of this "ignoring all but the first one" approach, because you are giving semantic meaning to multiple privilege authorities, saying that the first one is special and *will* get you anything you need. Keeping backwards compatibility for all future revs of the specification reduces to always keeping a "singular" privilege authority around and in the first position. This of course reduces to, guess what? Cheers, -Polar > ------End of proposed resolution------- > A subordinate issue was also raised; that being how to partition the > namespace of ServiceConfiguration syntax identifiers to support the > definition of vendor specific syntaxes. I created a new issue for this, > as > I do not know how this is done in Corba. I know some structure is > imposed on the collection of bits of the integer, such that some bits > efectively identifier a vendor, and others identify a syntax of the > vendor, but I do not know the details. So, I chose to create a separate > issue (hopefully to be resolved by someone more knowlegeable of these > details). > s the client Date: Fri, 13 Apr 2001 11:49:26 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types References: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id f3DFj7r17182 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: =+ > Hi, > > I do not agree with some of the text below. > > On Wed, 11 Apr 2001, Ron Monzillo wrote: > > > Issue 4118: Multiple Privilege Authorities and Supported Naming Types > > > > base document: > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > This issue argues that the specification of multiple privilege > > authorities in a target IOR unnecessarily complicate> > authorization token acquisition logic, especially as the semantics of > > multiple privilege authorities are not completely defined. > > > > Proposed Resolution: > > > > [1] replace paragraph 148 with the following paragraph > > > > The privilege_authorities field contains a list of the names of 0 or > > more privilege authorities. A non-empty list indicates that the target > > supports authorization tokens provided by a CSS (in EstablishContext > > messages) and containing AuthorizationElements from the authority named > > by the first ServiceConfiguration element in the list. If the > > privilege_authorities field contains more than one ServiceConfiguration > > element, A CSS shall be conformant if it ignores all > > ServiceConfiguration elements beyond the first. The syntax field within > > the ServiceConfiguration element identifies the format used to represent > > the authority. Two alternative formats are currently defined: an ASN.1 > > encoding of the GeneralNames (as defined in [IETF RFC 2459]) which > > identify a privilege authority, or a GSS exported name (as defined in > > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > > authority. It seems to me that the proposal above pretty much captures what we agreed to in the meeting. I know Polar wants something else, as articulated in his comments, and to some extent in the meeting, but that is not what we agreed to in the meeting. > Why don't I take a crack at it? My main beef with this is talking about > conformance of CSSs in this part of the spec. Let's talk about the > protocol. What is wrong with stating precisely what a conformant implementation should do in the standard? I thought that is what the normative part of the specification was all about. Jishnu. s the client From: "David Chizmadia" To: References: <3AD72006.955066F2@hp.com> Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types Date: Fri, 13 Apr 2001 12:41:32 -0400 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 2hj!!~a7e99"Le9c,]d9 From: "Jishnu Mukerji" Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types > > > [1] replace paragraph 148 with the following paragraph > > > > > > The privilege_authorities field contains a list of the names of > > >0 or > > > more privilege authorities. A non-empty list indicates that the > > >target > > > supports authorization tokens provided by a CSS (in > > >EstablishContext > > > messages) and containing AuthorizationElements from the > > >authority named > > > by the first ServiceConfiguration element in the list. If the > > > privilege_authorities field contains more than one ServiceConfiguration > > > element, A CSS shall be conformant if it ignores all > > > ServiceConfiguration elements beyond the first. I would suggest that this last sentence be changed to read "A CSS shall process only the first ServiceConfiguration element in a non-empty privilege_authorities field." While it isn't as strong as raising an error, removing the conditional makes the spec slightly less ambiguous about the defined protocol processing. I, too, believe that any reference to "conformance" here is redundant, since conformance is just implementation of a defined set of "Shall"s. > > > The syntax field within > > > the ServiceConfiguration element identifies the format used to represent > > > the authority. Two alternative formats are currently defined: an > > > ASN.1 > > > encoding of the GeneralNames (as defined in [IETF RFC 2459]) > > > which > > > identify a privilege authority, or a GSS exported name (as > > > defined in > > > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > > > authority. > > It seems to me that the proposal above pretty much captures what we > agreed to in the meeting. I know Polar wants something else, as > articulated in his comments, and to some extent in the meeting, but > > > that > is not what we agreed to in the meeting. > > > Why don't I take a crack at it? My main beef with this is talking > > > about > > conformance of CSSs in this part of the spec. Let's talk about > > > the > > protocol. > > What is wrong with stating precisely what a conformant > > > implementation > should do in the standard? I thought that is what the normative part > > > of > the specification was all about. > > Jishnu. > Date: Fri, 13 Apr 2001 13:14:11 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: David Chizmadia Cc: csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types References: <3AD72006.955066F2@hp.com> <001c01c0c438$9ba0e740$a000a8c0@davidch> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +WP!!g!?!!c"Yd9pF,e9 David Chizmadia wrote: > From: "Jishnu Mukerji" > Subject: Re: Proposed resolution to issue 4118: Multiple Privilege > Authoritiesand Supported Naming Types > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > The privilege_authorities field contains a list of the names > of 0 or > > > > more privilege authorities. A non-empty list indicates that > the target > > > > supports authorization tokens provided by a CSS (in > EstablishContext > > > > messages) and containing AuthorizationElements from the > authority > named > > > > by the first ServiceConfiguration element in the list. If the > > > > privilege_authorities field contains more than one > ServiceConfiguration > > > > element, A CSS shall be conformant if it ignores all > > > > ServiceConfiguration elements beyond the first. > > I would suggest that this last sentence be changed to read "A CSS > shall > process only the first ServiceConfiguration element in a non-empty > privilege_authorities field." While it isn't as strong as raising > an error, > removing the conditional makes the spec slightly less ambiguous > about the > defined protocol processing. I, too, believe that any reference to > "conformance" here is redundant, since conformance is just > implementation of > a defined set of "Shall"s. I see the problem with the conditional that you mention. However, "shall process *only* the first element", could be interpreted to means that any CSS that happens to process the second element too for whatever reason is non-conformant. I got the impression that we were explicitly trying to leave the possibility of experimental implementations that use the second element etc. open, and not force implementations that do so to become non-conformant. That is why I though what was agreed to was something like: "A CSS shall process the first ServiceConfiguration element. Processing of any additional ServiceContext elements is not required." Additionally we could allow servers to choose to be stricter by saying that "A CSS may choose to reject a request that comes with multiple ServiceConfiguration elements, in which case they should document the fact that the implementation rejects requests that come with more than one ServiceConfiiguration element." Inclusion of this would allow the creation of OSSs that strictly do not accept additional ServiceConfiguration elements, while allowing for implementations that do. We could also add a clarifying footnote or some such, which says something like "For a CSS to meaningfully process any ServiceConfiguration elements other than the first, there must be an out of band agreement in place between the client OSS and the server OSS defining the semantics of such usage, since this standard does not ascribe any specific meaning to such usage. This option is included mostly to enable experimental use, without forcing such experimental implementations into becoming non-conformant." Does that cover all bases? I will be happy to propose a reworded resolution along these lines if the above covers all bases for everyone. Cheers, Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Apr 2001 13:13:24 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: Ron Monzillo , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types In-Reply-To: <3AD72006.955066F2@hp.com> Message-ID: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by emerald.omg.org id f3DHFPr18902 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-UIDL: ?3pd9Vi^d9C-e!!)gMd9 Jishnu, You have your own perception of what we agreed to on the phone, just as I am sure Ron, I, and anybody else on the phone that day does. So here's my perception: We agreed that we would keep the sequence and state that only the first one is *somewhat* paid attention to, *but* it wasn't clear after that what would be the constraints or behavior. I also heard directly from you on the phone that "we must make sure what we do tomorrow doesn't break what we do today." Maybe that *WASN'T* in the agreement? We agreed that we would come up with some wording and then it would be refined. I am powerless in this group, as are many of the others, to do anything at all. So all I can do is just to provide logical arguments about they way something is written and what it actually implies, and hopefully, it has some sane effect. Have a nice holiday if you do that sort of thing, -Polar On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > Hi, > > > > I do not agree with some of the text below. > > > > On Wed, 11 Apr 2001, Ron Monzillo wrote: > > > > > Issue 4118: Multiple Privilege Authorities and Supported Naming Types > > > > > > base document: > > > > > > http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf > > > > > > This issue argues that the specification of multiple privilege > > > authorities in a target IOR unnecessarily complicate> > > authorization token acquisition logic, especially as the semantics of > > > multiple privilege authorities are not completely defined. > > > > > > Proposed Resolution: > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > The privilege_authorities field contains a list of the names of 0 or > > > more privilege authorities. A non-empty list indicates that the target > > > supports authorization tokens provided by a CSS (in EstablishContext > > > messages) and containing AuthorizationElements from the authority named > > > by the first ServiceConfiguration element in the list. If the > > > privilege_authorities field contains more than one ServiceConfiguration > > > element, A CSS shall be conformant if it ignores all > > > ServiceConfiguration elements beyond the first. The syntax field within > > > the ServiceConfiguration element identifies the format used to represent > > > the authority. Two alternative formats are currently defined: an ASN.1 > > > encoding of the GeneralNames (as defined in [IETF RFC 2459]) which > > > identify a privilege authority, or a GSS exported name (as defined in > > > [IETF RFC 2743] Section 3.2) encoding of the name of a privilege > > > authority. > > It seems to me that the proposal above pretty much captures what we > agreed to in the meeting. I know Polar wants something else, as > articulated in his comments, and to some extent in the meeting, but that > is not what we agreed to in the meeting. > > > Why don't I take a crack at it? My main beef with this is talking about > > conformance of CSSs in this part of the spec. Let's talk about the > > protocol. > > What is wrong with stating precisely what a conformant implementation > should do in the standard? I thought that is what the normative part of > the specification was all about. > > Jishnu. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Apr 2001 13:39:46 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: David Chizmadia , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types In-Reply-To: <3AD733E3.B27EB588@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: %>0!!l3:!!e[Sd9-'>!! On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > David Chizmadia wrote: > > > From: "Jishnu Mukerji" > > Subject: Re: Proposed resolution to issue 4118: Multiple Privilege > > Authoritiesand Supported Naming Types > > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > > > The privilege_authorities field contains a list of the names >of 0 or > > > > > more privilege authorities. A non-empty list indicates that >the target > > > > > supports authorization tokens provided by a CSS (in >EstablishContext > > > > > messages) and containing AuthorizationElements from the >authority > > named > > > > > by the first ServiceConfiguration element in the list. If >the > > > > > privilege_authorities field contains more than one > > ServiceConfiguration > > > > > element, A CSS shall be conformant if it ignores all > > > > > ServiceConfiguration elements beyond the first. > > > > I would suggest that this last sentence be changed to read "A CSS >shall > > process only the first ServiceConfiguration element in a non-empty > > privilege_authorities field." While it isn't as strong as raising >an error, > > removing the conditional makes the spec slightly less ambiguous >about the > > defined protocol processing. I, too, believe that any reference >to > > "conformance" here is redundant, since conformance is just >implementation of > > a defined set of "Shall"s. > > I see the problem with the conditional that you mention. > > However, "shall process *only* the first element", could be >interpreted to means > that any CSS that happens to process the second element too for >whatever reason > is non-conformant. Non-conformance here isn't the issue. If the target produces more than one privilege authority, the client has no way of figuring out what do do with it, unless it has an extraordinary agreement with that server. Operating as such, doesn't make the implemenation of the CSS non-conformant. However, the mere fact that a conformant CSS is only required to process the first one, ignoring the subsequent ones, IMPLIES that in that a conformant TSS must produce a singular privilege authority in the first element to operate with all conformant CSSs (since they only support the first). This calls out some specific semantics about privilege authorities and multiples of them, namely the first one has to produce everything that any combinaation of the others may. I'm not so sure you want to be that restrictive explicitly or implicitly, eh? So, the basic upshot is that with "ignoring all but the first", every target must produce a singular privilege authority to get everything it needs, if it produces one or more at all. I'm not in favor of saying anything about what a "conforming CSS" will do. I am in favor of just stating the facts about the protocol. That's why I proposed the REALLY REALLY SIMPLE wording of: ---- The privilege_authorities field contains a sequence of at most one ServiceConfiguration. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. The syntax field .... ---- This leaves CSSs to do what ever they want with regard to multiple privilege authorities, because it is outside of the spec. It can ignore the security mechanism, or process the first one, or the second one, or whatever. And it allows targets to put multiples in there to interoperate with such clients. If it wants to interoperate with regular CSIv2 clients, it has to produce a security mechanism with one privilege authority in it. That is not to say it cannot produce other security mechanisms with multiples. And furthermore, it does nothing toward implying that the first privilege authority must be the be-all-end-all of privilege authorities for that security mechanism. Cheers, -Polar ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: <3AD72006.955066F2@hp.com> <001c01c0c438$9ba0e740$a000a8c0@davidch> <3AD733E3.B27EB588@hp.com> Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types Date: Fri, 13 Apr 2001 13:49:50 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: O!d!!3XBe9:E\!!/\"e9 Jishnu Mukerji wrote: > > David Chizmadia wrote: > < Some text deleted...> > > I would suggest that this last sentence be changed to read "A CSS shall > > process only the first ServiceConfiguration element in a non-empty > > privilege_authorities field." While it isn't as strong as raising an error, > > removing the conditional makes the spec slightly less ambiguous about the > > defined protocol processing. I, too, believe that any reference to > > "conformance" here is redundant, since conformance is just implementation of > > a defined set of "Shall"s. > > I see the problem with the conditional that you mention. > > However, "shall process *only* the first element", could be interpreted to means > that any CSS that happens to process the second element too for whatever reason > is non-conformant. Exactly! From a protocol conformance perspective (which is fundamentally a marketing issue if the implementation is intelligently designed), this would be true. As I'll discuss below, experimental extensions aren't obligated to conform and therefore don't care. > I got the impression that we were explicitly trying to leave > the possibility of experimental implementations that use the second element etc. > open, and not force implementations that do so to become > non-conformant. That is > why I though what was agreed to was something like: "A CSS shall > process the > first ServiceConfiguration element. Processing of any additional ServiceContext > elements is not required." I'll admit that I was distracted during this part of the discussion, but even so, I consider that the interoperability that Polar is striving for is better served by a strict interpretation of "conformance." My view is that an experimental extensions OSS is indeed "non-conformant", but in practice - who cares! If it provides a switch to disable the experimental extensions, then there is at least one configuration of the product that is conformant and therefore the product can be advertised as "conformant." In truth, because the processing of additional ServiceConfiguration elements is a strict superset of conformant processing, either side of the OSS will still be interoperable with strictly conformant implementations. The reverse cannot be guaranteed unless some degree of intelligent thought actually went into the design of the extensions. > > Additionally we could allow servers to choose to be stricter by >saying that "A > CSS may choose to reject a request that comes with multiple ServiceConfiguration > elements, in which case they should document the fact that the implementation > rejects requests that come with more than one ServiceConfiiguration element." > Inclusion of this would allow the creation of OSSs that strictly do >not accept > additional ServiceConfiguration elements, while allowing for implementations > that do. > > We could also add a clarifying footnote or some such, which says >something like > "For a CSS to meaningfully process any ServiceConfiguration elements >other than > the first, there must be an out of band agreement in place between >the client > OSS and the server OSS defining the semantics of such usage, since >this standard > does not ascribe any specific meaning to such usage. This option is included > mostly to enable experimental use, without forcing such experimental > implementations into becoming non-conformant." > > Does that cover all bases? I will be happy to propose a reworded resolution > along these lines if the above covers all bases for everyone. I don't see any real need to state any of the caveats. The industry moves forward on the basis of customer demand. If there is money to be made, companies will do everything in the caveats whether we bless it or not. The goal of the standard is to promote interoperability by defining at least one set of message formats and protocol processing rules with enough precision to allow intelligent communication conforming to the principle of least surprise. I think that the relatively small change I suggested does that. > > Cheers, > > Jishnu. -DMC Date: Fri, 13 Apr 2001 14:00:25 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: Ron Monzillo , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: l@fd9Wg9e9-:9e9;*]!! Polar Humenn wrote: > Jishnu, > > You have your own perception of what we agreed to on the phone, just >as I > am sure Ron, I, and anybody else on the phone that day does. > > So here's my perception: > > We agreed that we would keep the sequence and state that only the >first > one is *somewhat* paid attention to, *but* it wasn't clear after >that what > would be the constraints or behavior. Polar, I missed the point that you were trying to make in your message. I got all wrapped around whether it was OK or not for the normative part of a spec to mention the word "conformant" in it.:-) Sorry about that. I agreed with David that there was a bit of ambiguity in the proposed text and have proposed much tighter text addressing it, building on the text change that David proposed. Let me know if that covers the bases that need covering to tighten things up. > I also heard directly from you on the phone that "we must make sure what > we do tomorrow doesn't break what we do today." Maybe that *WASN'T* in the > agreement? We agreed that we would come up with some wording and then it > would be refined. We are in the process of doing so as we speak/write/type whatever.:-) > I am powerless in this group, as are many of the others, to do anything at > all. So all I can do is just to provide logical arguments about they way > something is written and what it actually implies, and hopefully, it has > some sane effect. I am taking them quite seriously, as you will see in my response to David's message. He actually did a pretty good job of explaining where you were coming from I think. Again, I am sorry for having missed that. > Have a nice holiday if you do that sort of thing, > I do so only on holidays.:-) You see, today is not a holiday for us. So I shall start indulging in those activities a little after 5pm today.:-) Cheers, Jishnu. Date: Fri, 13 Apr 2001 14:14:31 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FhY!!]8nd9$\)e9V;gd9 Polar Humenn wrote: > On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > > > > > David Chizmadia wrote: > > > > > From: "Jishnu Mukerji" > > > Subject: Re: Proposed resolution to issue 4118: Multiple >Privilege > > > Authoritiesand Supported Naming Types > > > > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > > > > > The privilege_authorities field contains a list of the >names of 0 or > > > > > > more privilege authorities. A non-empty list indicates >that the target > > > > > > supports authorization tokens provided by a CSS (in >EstablishContext > > > > > > messages) and containing AuthorizationElements from the >authority > > > named > > > > > > by the first ServiceConfiguration element in the list. If >the > > > > > > privilege_authorities field contains more than one > > > ServiceConfiguration > > > > > > element, A CSS shall be conformant if it ignores all > > > > > > ServiceConfiguration elements beyond the first. > > > > > > I would suggest that this last sentence be changed to read "A >CSS shall > > > process only the first ServiceConfiguration element in a >non-empty > > > privilege_authorities field." While it isn't as strong as >raising an error, > > > removing the conditional makes the spec slightly less ambiguous >about the > > > defined protocol processing. I, too, believe that any reference >to > > > "conformance" here is redundant, since conformance is just >implementation of > > > a defined set of "Shall"s. > > > > I see the problem with the conditional that you mention. > > > > However, "shall process *only* the first element", could be >interpreted to means > > that any CSS that happens to process the second element too for >whatever reason > > is non-conformant. > > Non-conformance here isn't the issue. If the target produces more >than one > privilege authority, the client has no way of figuring out what do >do with > it, unless it has an extraordinary agreement with that server. >Operating > as such, doesn't make the implemenation of the CSS non-conformant. > > However, the mere fact that a conformant CSS is only required to >process > the first one, ignoring the subsequent ones, IMPLIES that in that a > conformant TSS must produce a singular privilege authority in the >first > element to operate with all conformant CSSs (since they only support >the > first). This calls out some specific semantics about privilege > authorities and multiples of them, namely the first one has to >produce > everything that any combinaation of the others may. I'm not so sure >you > want to be that restrictive explicitly or implicitly, eh? > > So, the basic upshot is that with "ignoring all but the first", >every > target must produce a singular privilege authority to get everything >it > needs, if it produces one or more at all. It is true that the first must produce a valid choice. However, additional ones may be used to modulate that choice even though the first choice is potentially valid. For example in a hypothetical situation, the second one may provide a more efficient choice for those that happen to know how to use it, while those that don't can safely use the first one. Does not do nay harm to CSS clients that are unaware of the additional flexibility. They can follow the rule of use the first one only. > I'm not in favor of saying anything about what a "conforming CSS" will do. > I am in favor of just stating the facts about the protocol. > > That's why I proposed the REALLY REALLY SIMPLE wording of: > > ---- > The privilege_authorities field contains a sequence of at most one > ServiceConfiguration. A non-empty sequence indicates that the target > supports the CSS delivery of an AuthorizationToken, which is delivered in > the EstablishContext message. The syntax field .... > ---- > > This leaves CSSs to do what ever they want with regard to multiple > privilege authorities, because it is outside of the spec. It can ignore > the security mechanism, or process the first one, or the second one, or > whatever. > > And it allows targets to put multiples in there to interoperate with such > clients. If it wants to interoperate with regular CSIv2 clients, it has to > produce a security mechanism with one privilege authority in it. That is > not to say it cannot produce other security mechanisms with multiples. And > furthermore, it does nothing toward implying that the first privilege > authority must be the be-all-end-all of privilege authorities for that > security mechanism. The issue is mostly with what is or is not conformant on the wire. A very strict conformance test would reject a handshake that did put multiple service configurations on the wire. We would like to avoid that. As long as it is OK to place multiple service configurations on the wire, knowing fully well that only one of those will be used by the conformant implementation, I am happy. The language you propose seems to have a possible reading that would prevent that from being done. That is what I would find problematic. Jishnu. Date: Fri, 13 Apr 2001 14:21:53 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: David Chizmadia Cc: csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types References: <3AD72006.955066F2@hp.com> <001c01c0c438$9ba0e740$a000a8c0@davidch> <3AD733E3.B27EB588@hp.com> <003301c0c442$23a25260$a000a8c0@davidch> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: #CE!!FaF!!mDmd91m]d9 David Chizmadia wrote: > Jishnu Mukerji wrote: > > > > David Chizmadia wrote: > > > < Some text deleted...> > > > > I would suggest that this last sentence be changed to read "A CSS shall > > > process only the first ServiceConfiguration element in a non-empty > > > privilege_authorities field." While it isn't as strong as raising an > error, > > > removing the conditional makes the spec slightly less ambiguous about > the > > > defined protocol processing. I, too, believe that any reference to > > > "conformance" here is redundant, since conformance is just > implementation of > > > a defined set of "Shall"s. > > > > I see the problem with the conditional that you mention. > > > > However, "shall process *only* the first element", could be interpreted to > means > > that any CSS that happens to process the second element too for whatever > reason > > is non-conformant. > > Exactly! From a protocol conformance perspective (which is fundamentally a > marketing issue if the implementation is intelligently designed), this would > be true. As I'll discuss below, experimental extensions aren't obligated to > conform and therefore don't care. > > > I got the impression that we were explicitly trying to leave > > the possibility of experimental implementations that use the second > element etc. > > open, and not force implementations that do so to become non-conformant. > That is > > why I though what was agreed to was something like: "A CSS shall process > the > > first ServiceConfiguration element. Processing of any additional > ServiceContext > > elements is not required." > > I'll admit that I was distracted during this part of the discussion, but > even so, I consider that the interoperability that Polar is striving for is > better served by a strict interpretation of "conformance." My view is that > an experimental extensions OSS is indeed "non-conformant", but in practice - > who cares! > If it provides a switch to disable the experimental extensions, > then there is at least one configuration of the product that is > conformant > and therefore the product can be advertised as "conformant." In > truth, > because the processing of additional ServiceConfiguration elements > is a > strict superset of conformant processing, either side of the OSS > will still > be interoperable with strictly conformant implementations. The > reverse > cannot be guaranteed unless some degree of intelligent thought > actually went > into the design of the extensions. Yes, and the language that I propose gives you all that. Which part of your strict conformance requirement is unobtainable given the language that I proposed? > > > > Additionally we could allow servers to choose to be stricter by > >saying > that "A > > CSS may choose to reject a request that comes with multiple > ServiceConfiguration > > elements, in which case they should document the fact that the > implementation > > rejects requests that come with more than one > >ServiceConfiiguration > element." > > Inclusion of this would allow the creation of OSSs that strictly > >do not > accept > > additional ServiceConfiguration elements, while allowing for > implementations > > that do. > > > > We could also add a clarifying footnote or some such, which says > >something > like > > "For a CSS to meaningfully process any ServiceConfiguration > >elements other > than > > the first, there must be an out of band agreement in place between > >the > client > > OSS and the server OSS defining the semantics of such usage, since > >this > standard > > does not ascribe any specific meaning to such usage. This option > >is > included > > mostly to enable experimental use, without forcing such > >experimental > > implementations into becoming non-conformant." > > > > Does that cover all bases? I will be happy to propose a reworded > resolution > > along these lines if the above covers all bases for everyone. > > I don't see any real need to state any of the caveats. OK, we will just have to agree to disagree on that. > The industry moves > forward on the basis of customer demand. If there is money to be > made, > companies will do everything in the caveats whether we bless it or > not. The > goal of the standard is to promote interoperability by defining at > least one > set of message formats and protocol processing rules with enough > precision > to allow intelligent communication conforming to the principle of > least > surprise. I think that the relatively small change I suggested does > that. And I have done so in the proposed text. So now you want me to remove all caveats, even though you got what you want because you find caveats distasteful?:-). Cheers, Jishnu. From: "Dushin, Fred" To: jishnu_mukerji@hp.com Cc: David Chizmadia , csiv2-ftf@omg.org, "Humenn, Polar" Message-ID: <3AD742CE.7D5FAFE9@hitachisoftware.com> Date: Fri, 13 Apr 2001 14:17:50 -0400 Organization: Hitachi Computer Products (America), Inc. X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Proposed resolution to issue 4118: Multiple Privilege Authoritiesand Supported Naming Types References: <3AD72006.955066F2@hp.com> <001c01c0c438$9ba0e740$a000a8c0@davidch> <3AD733E3.B27EB588@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-UIDL: bBMd9Lm~!!d=L!!Wf(!! > We could also add a clarifying footnote or some such, which says something like > "For a CSS to meaningfully process any ServiceConfiguration elements other than > the first, there must be an out of band agreement in place between the client > OSS and the server OSS defining the semantics of such usage, since this standard > does not ascribe any specific meaning to such usage. This option is included > mostly to enable experimental use, without forcing such experimental > implementations into becoming non-conformant." I think some sort of footnote will be required, since any statement to the effect that a sequence SHALL or MUST be at most length 1 (or be conformant) will beg the question, "Why not use a bounded sequence, then?" The spec reader who is not privy to these discussions will no doubt ask why. Like Polar, I prefer to keep "conformance" out of the discussion; we have the words SHALL and SHOULD (though I don't know if these are as well defined in the OMG's specs as in others'), which are at least no more vague than their usage in the rest of the spec. Conformance seems like a different issue. /Fred -- Fred Dushin mailto:fadushin@hi.com Hitachi Computer Products tel: (781) 768-5827 X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Apr 2001 14:25:03 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: David Chizmadia , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types In-Reply-To: <3AD74207.FE6FFB91@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: f>M!!01?e95>C!!jpld9 On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > Polar Humenn wrote: > > > On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > > > > > > > > > David Chizmadia wrote: > > > > > > > From: "Jishnu Mukerji" > > > > Subject: Re: Proposed resolution to issue 4118: Multiple >Privilege > > > > Authoritiesand Supported Naming Types > > > > > > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > > > > > > > The privilege_authorities field contains a list of the >names of 0 or > > > > > > > more privilege authorities. A non-empty list indicates >that the target > > > > > > > supports authorization tokens provided by a CSS (in >EstablishContext > > > > > > > messages) and containing AuthorizationElements from the >authority > > > > named > > > > > > > by the first ServiceConfiguration element in the >list. If the > > > > > > > privilege_authorities field contains more than one > > > > ServiceConfiguration > > > > > > > element, A CSS shall be conformant if it ignores all > > > > > > > ServiceConfiguration elements beyond the first. > > > > > > > > I would suggest that this last sentence be changed to read "A >CSS shall > > > > process only the first ServiceConfiguration element in a >non-empty > > > > privilege_authorities field." While it isn't as strong as >raising an error, > > > > removing the conditional makes the spec slightly less >ambiguous about the > > > > defined protocol processing. I, too, believe that any >reference to > > > > "conformance" here is redundant, since conformance is just >implementation of > > > > a defined set of "Shall"s. > > > > > > I see the problem with the conditional that you mention. > > > > > > However, "shall process *only* the first element", could be >interpreted to means > > > that any CSS that happens to process the second element too for >whatever reason > > > is non-conformant. > > > > Non-conformance here isn't the issue. If the target produces more >than one > > privilege authority, the client has no way of figuring out what do >do with > > it, unless it has an extraordinary agreement with that server. >Operating > > as such, doesn't make the implemenation of the CSS non-conformant. > > > > However, the mere fact that a conformant CSS is only required to >process > > the first one, ignoring the subsequent ones, IMPLIES that in that >a > > conformant TSS must produce a singular privilege authority in the >first > > element to operate with all conformant CSSs (since they only >support the > > first). This calls out some specific semantics about privilege > > authorities and multiples of them, namely the first one has to >produce > > everything that any combinaation of the others may. I'm not so >sure you > > want to be that restrictive explicitly or implicitly, eh? > > > > So, the basic upshot is that with "ignoring all but the first", >every > > target must produce a singular privilege authority to get >everything it > > needs, if it produces one or more at all. > > It is true that the first must produce a valid choice. However, >additional ones may be > used to modulate that choice even though the first choice is >potentially valid. For > example in a hypothetical situation, the second one may provide a >more efficient > choice for those that happen to know how to use it, while those that >don't can safely > use the first one. Does not do nay harm to CSS clients that are >unaware of the > additional flexibility. They can follow the rule of use the first >one only. > > > I'm not in favor of saying anything about what a "conforming CSS" >will do. > > I am in favor of just stating the facts about the protocol. > > > > That's why I proposed the REALLY REALLY SIMPLE wording of: > > > > ---- > > The privilege_authorities field contains a sequence of at most one > > ServiceConfiguration. A non-empty sequence indicates that the >target > > supports the CSS delivery of an AuthorizationToken, which is >delivered in > > the EstablishContext message. The syntax field .... > > ---- > > > > This leaves CSSs to do what ever they want with regard to multiple > > privilege authorities, because it is outside of the spec. It can >ignore > > the security mechanism, or process the first one, or the second >one, or > > whatever. > > > > And it allows targets to put multiples in there to interoperate >with such > > clients. If it wants to interoperate with regular CSIv2 clients, >it has to > > produce a security mechanism with one privilege authority in >it. That is > > not to say it cannot produce other security mechanisms with >multiples. And > > furthermore, it does nothing toward implying that the first >privilege > > authority must be the be-all-end-all of privilege authorities for >that > > security mechanism. > > The issue is mostly with what is or is not conformant on the wire. A > very strict conformance test would reject a handshake that did put > multiple service configurations on the wire. Well, with the wording I produced, accepting and rejecting the handshake would be conformant behavior, which is the behavior you want. Because, if given multiple privilege authorities a conformant CSS could reject the handshake based on other principles because it has extraneous behavior of knowing about mulitiple privilege authorities and two of them cause the CSS security mechanism to fail. So, are you saying that it should *first* try to handle multiple privilege authorities (what ever that means?), and THEN if that doesn't work, only work with the first one? > We would like to avoid > that. As long as it is OK to place multiple service configurations > on > the wire, knowing fully well that only one of those will be used by > the conformant implementation, I am happy. Hmmmmm, now, what you are doing is giving semantics to multiple privilege authorities such that "only one" of them shall be used? Is this a failover mechanism? Is it a redudnacy mechanism? Is it a avaiablity mechanism? At one point, I heard Ron talking about getting elements from each of them. > The language you propose seems to have a possible reading that would > prevent that from being done. That is what I would find problematic. It all depends on the semantics for multiple privilege authorities that you want. What ever it is, it better be spelled out, and it would be really nice if the consequences were thought of thorooughly. Having regular CSIv2 clients ignore all but the first, puts the diliegence on CSIv2 targets to always to have a certain semantics for multiple privilege authorities, meaning that the first *always* must give you the correct answer, and puts the diliegence on the client to come up with accepting the first one, even when it thinks it's interpretation of multiples is wrong. Cheers, -Polar > Jishnu. > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Fri, 13 Apr 2001 16:28:05 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *4fd9URMe9:de!!&e>e9 Polar Humenn wrote: > On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > > > > > Polar Humenn wrote: > > > > > On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > > > > > > > > > > > > > David Chizmadia wrote: > > > > > > > > > From: "Jishnu Mukerji" > > > > > Subject: Re: Proposed resolution to issue 4118: Multiple >Privilege > > > > > Authoritiesand Supported Naming Types > > > > > > > > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > > > > > > > > > > > The privilege_authorities field contains a list of the >names of 0 or > > > > > > > > more privilege authorities. A non-empty list indicates >that the target > > > > > > > > supports authorization tokens provided by a CSS (in >EstablishContext > > > > > > > > messages) and containing AuthorizationElements from >the authority > > > > > named > > > > > > > > by the first ServiceConfiguration element in the >list. If the > > > > > > > > privilege_authorities field contains more than one > > > > > ServiceConfiguration > > > > > > > > element, A CSS shall be conformant if it ignores all > > > > > > > > ServiceConfiguration elements beyond the first. > > > > > > > > > > I would suggest that this last sentence be changed to read >"A CSS shall > > > > > process only the first ServiceConfiguration element in a >non-empty > > > > > privilege_authorities field." While it isn't as strong as >raising an error, > > > > > removing the conditional makes the spec slightly less >ambiguous about the > > > > > defined protocol processing. I, too, believe that any >reference to > > > > > "conformance" here is redundant, since conformance is just >implementation of > > > > > a defined set of "Shall"s. > > > > > > > > I see the problem with the conditional that you mention. > > > > > > > > However, "shall process *only* the first element", could be >interpreted to means > > > > that any CSS that happens to process the second element too >for whatever reason > > > > is non-conformant. > > > > > > Non-conformance here isn't the issue. If the target produces >more than one > > > privilege authority, the client has no way of figuring out what >do do with > > > it, unless it has an extraordinary agreement with that server. >Operating > > > as such, doesn't make the implemenation of the CSS >non-conformant. > > > > > > However, the mere fact that a conformant CSS is only required to >process > > > the first one, ignoring the subsequent ones, IMPLIES that in >that a > > > conformant TSS must produce a singular privilege authority in >the first > > > element to operate with all conformant CSSs (since they only >support the > > > first). This calls out some specific semantics about privilege > > > authorities and multiples of them, namely the first one has to >produce > > > everything that any combinaation of the others may. I'm not so >sure you > > > want to be that restrictive explicitly or implicitly, eh? > > > > > > So, the basic upshot is that with "ignoring all but the first", >every > > > target must produce a singular privilege authority to get >everything it > > > needs, if it produces one or more at all. > > > > It is true that the first must produce a valid choice. However, >additional ones may be > > used to modulate that choice even though the first choice is >potentially valid. For > > example in a hypothetical situation, the second one may provide a >more efficient > > choice for those that happen to know how to use it, while those >that don't can safely > > use the first one. Does not do nay harm to CSS clients that are >unaware of the > > additional flexibility. They can follow the rule of use the first >one only. > > > > > I'm not in favor of saying anything about what a "conforming >CSS" will do. > > > I am in favor of just stating the facts about the protocol. > > > > > > That's why I proposed the REALLY REALLY SIMPLE wording of: > > > > > > ---- > > > The privilege_authorities field contains a sequence of at most >one > > > ServiceConfiguration. A non-empty sequence indicates that the >target > > > supports the CSS delivery of an AuthorizationToken, which is >delivered in > > > the EstablishContext message. The syntax field .... > > > ---- > > > > > > This leaves CSSs to do what ever they want with regard to >multiple > > > privilege authorities, because it is outside of the spec. It >can ignore > > > the security mechanism, or process the first one, or the second >one, or > > > whatever. > > > > > > And it allows targets to put multiples in there to interoperate >with such > > > clients. If it wants to interoperate with regular CSIv2 clients, >it has to > > > produce a security mechanism with one privilege authority in >it. That is > > > not to say it cannot produce other security mechanisms with >multiples. And > > > furthermore, it does nothing toward implying that the first >privilege > > > authority must be the be-all-end-all of privilege authorities >for that > > > security mechanism. > > > > The issue is mostly with what is or is not conformant on the >wire. A > > very strict conformance test would reject a handshake that did put > > multiple service configurations on the wire. > > Well, with the wording I produced, accepting and rejecting the >handshake > would be conformant behavior, which is the behavior you >want. Because, if > given multiple privilege authorities a conformant CSS could reject >the > handshake based on other principles because it has extraneous >behavior of > knowing about mulitiple privilege authorities and two of them cause >the > CSS security mechanism to fail. I think I just made that very explicit. Is there something wrong with that? > So, are you saying that it should *first* try to handle multiple privilege > authorities (what ever that means?), and THEN if that doesn't work, only > work with the first one? No, where did I say anything that could be inteerpreted that way? We may be talking passed each other here. I am talking about conformance test results, and you are talking about accepting and rejecting handshake. Yes, accepting/rejecting handshake is part of the conformance test. Additional parts could be exactly what is placed on the wire. I was talking about whether the presence of the additional service element on the wire would render the implementation non-conformant. > > We would like to avoid > > that. As long as it is OK to place multiple service > > configurations on > > the wire, knowing fully well that only one of those will be used > > by > > the conformant implementation, I am happy. > > Hmmmmm, now, what you are doing is giving semantics to multiple > > privilege > authorities such that "only one" of them shall be used? Is this a > > failover > mechanism? Is it a redudnacy mechanism? Is it a avaiablity > > mechanism? At > one point, I heard Ron talking about getting elements from each of > > them. The standard behavior is that the first one will be the one that will be used. that's it. Use of anything else is outside the scope of the standard. The stuff outside the standard can be experimented with for doing various things I suppose, but the standard specification need not dwell on that. > > The language you propose seems to have a possible reading that would > > prevent that from being done. That is what I would find problematic. > > It all depends on the semantics for multiple privilege authorities that > you want. What ever it is, it better be spelled out, and it would be > really nice if the consequences were thought of thorooughly. > The standard behavior has no semantics for multiple privilege authorities, as we have all agreed (I hope). > Having regular CSIv2 clients ignore all but the first, puts the diliegence > on CSIv2 targets to always to have a certain semantics for multiple > privilege authorities, meaning that the first *always* must give you the > correct answer, and puts the diliegence on the client to come up with > accepting the first one, even when it thinks it's interpretation of > multiples is wrong. > Not really. If the target says no way never shall I ever recognize or send more than one, and documents that, then that is it. They do not have to worry about multiples ever. A client that does goofy things outside of the standard is pretty much on its own. The diligence that you appear to be concerned about is one that the targets that want to use additional privilege authorities have to maintain, and this is something that only those target OSSs that do stuff beyond the standard with this field have to worry about. And in order for them to be conformant with the standard, the first of those must provide complete adequate info. Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Apr 2001 17:25:15 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: David Chizmadia , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types In-Reply-To: <3AD76155.6423FA67@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 97&!!Bej!!SS&e9a"p!! On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > Not really. If the target says no way never shall I ever recognize or send more than one, > and documents that, then that is it. They do not have to worry about multiples ever. A > client that does goofy things outside of the standard is pretty much on its own. The > diligence that you appear to be concerned about is one that the targets that want to use > additional privilege authorities have to maintain, and this is something that only those > target OSSs that do stuff beyond the standard with this field have to worry about. And in > order for them to be conformant with the standard, the first of those must provide complete > adequate info. Is that the semantics of multiple privilege authorities for the future? The first one is always the omnipotent one? I wouldn't disagree with that approach :) Because that means effectively that there is only ever one singluar privilege authority per security mechanism. This is exactly what I want, but my worry is on you guys who want to reserve the thought of multiple privilege authorities in the spec for something other than this restrictive approach. You're hosed if you adopt it. I don't care. Except let's keep the wording conscise and to the point. The privilege_authorities field contains a sequence of ServiceConfiguration. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. Should the sequence contain more than one element, the CSS shall ignore all, but the first one. The syntax field .... > Jishnu. > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types Date: Fri, 13 Apr 2001 20:18:26 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ek/e9&hQ!!!!Yd9/]5e9 ----- Original Message ----- From: "Polar Humenn" To: "Jishnu Mukerji" Cc: "David Chizmadia" ; Sent: Friday, April 13, 2001 5:25 PM Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types > On Fri, 13 Apr 2001, Jishnu Mukerji wrote: > > > > > Not really. If the target says no way never shall I ever recognize >or send more than one, > > and documents that, then that is it. They do not have to worry >about multiples ever. A > > client that does goofy things outside of the standard is pretty >much on its own. The > > diligence that you appear to be concerned about is one that the >targets that want to use > > additional privilege authorities have to maintain, and this is >something that only those > > target OSSs that do stuff beyond the standard with this field have >to worry about. And in > > order for them to be conformant with the standard, the first of >those must provide complete > > adequate info. > > Is that the semantics of multiple privilege authorities for the >future? > The first one is always the omnipotent one? > > I wouldn't disagree with that approach :) Because that means >effectively > that there is only ever one singluar privilege authority per >security > mechanism. > > This is exactly what I want, but my worry is on you guys who want to > reserve the thought of multiple privilege authorities in the spec >for > something other than this restrictive approach. You're hosed if you >adopt > it. > > I don't care. Except let's keep the wording conscise and to the >point. > > The privilege_authorities field contains a sequence of > ServiceConfiguration. A non-empty sequence indicates that the target > supports the CSS delivery of an AuthorizationToken, which is >delivered in > the EstablishContext message. Should the sequence contain more than >one > element, the CSS shall ignore all, but the first one. The syntax >field > .... Although not quite as concise as Polar's proposal above, I would like to suggest the following: [1] replace paragraph 148 with the following paragraph The privilege_authorities field contains a sequence of 0 or more ServiceConfiguration elements, each representing a valid privilege authority. The CSS shall always use the authority named in the first ServiceConfiguration element of a non-empty privilege_authorities field to acquire the AuthorizationElements it uses in its EstablishContext message. It it recommended that a CSS reject a request that comes with multiple ServiceConfiguration elements by raising an exception. {We'll need to identify the appropriate exception.} [footnote] For a CSS to acquire and reconcile AuthorizationElements acquired from authorities named in any additional ServiceConfiguration elements in the privilege_authorities field, there must be an out of band agreement in place between the client OSS and the server OSS defining the semantics of such usage, since this standard does not do so. This option is included mostly to enable experimental use of multiple privilege authorities, without forcing such experimental implementations into becoming non-conformant. I think that this paragraph, plus the footnote, captures the effect of Jishnu's suggestions below, while reversing their sense to reflect what (I think) Polar (and I) have been advocating should be "standard" CSIv2 behavior. > As such, a CSS may choose to reject a request that comes with > multiple ServiceConfiguration elements, in which case they > should document the fact that the implementation rejects > requests that come with more than one ServiceConfiguration > element." Inclusion of this would allow the creation of OSSs > that strictly do not accept additional ServiceConfiguration > elements, while allowing for implementations that do. > > We could also add a clarifying footnote or some such, which > says something like "For a CSS to meaningfully process any > ServiceConfiguration elements other than the first, there must > be an out of band agreement in place between the client OSS and > the server OSS defining the semantics of such usage, since this > standard does not ascribe any specific meaning to such usage. > This option is included mostly to enable experimental use, > without forcing such experimental implementations into becoming > non-conformant." I look forward to comments... -DMC X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Fri, 13 Apr 2001 21:14:56 -0400 (EDT) From: Polar Humenn To: David Chizmadia cc: Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types In-Reply-To: <007401c0c478$6d800540$a000a8c0@davidch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: gpg!!!'\d99?id9A0c!! On Fri, 13 Apr 2001, David Chizmadia wrote: Polar wrote: > > The privilege_authorities field contains a sequence of > > ServiceConfiguration. A non-empty sequence indicates that the target > > supports the CSS delivery of an AuthorizationToken, which is delivered in > > the EstablishContext message. Should the sequence contain more than one > > element, the CSS shall ignore all, but the first one. The syntax field > > .... > > Although not quite as concise as Polar's proposal above, I would like to > suggest the following: > > [1] replace paragraph 148 with the following paragraph > > The privilege_authorities field contains a sequence of 0 or more > ServiceConfiguration elements, each representing a valid privilege > authority. The CSS shall always use the authority named in the first > ServiceConfiguration element of a non-empty privilege_authorities field to > acquire the AuthorizationElements it uses in its EstablishContext message. > It it recommended that a CSS reject a request that comes with multiple > ServiceConfiguration elements by raising an exception. {We'll > need to identify the appropriate exception.} > > [footnote] > For a CSS to acquire and reconcile AuthorizationElements acquired from > authorities named in any additional ServiceConfiguration elements in the > privilege_authorities field, there must be an out of band agreement in place > between the client OSS and the server OSS defining the semantics of such > usage, since this standard does not do so. This option is included mostly > to enable experimental use of multiple privilege authorities, without > forcing such experimental implementations into becoming non-conformant. > > > I think that this paragraph, plus the footnote, captures the effect of > Jishnu's suggestions below, while reversing their sense to reflect what (I > think) Polar (and I) have been advocating should be "standard" CSIv2 > behavior. David, This is a litte over the top. I really don't think it is necessary to "recommend that a CSS reject a request...". Recommedations that aren't mandated in this field are really meaningless, and probably confusing. And also, that is not the behavior these guys want. They always want to deal with the first one. So, give it to them. The others are outside of the specification. Second of all, the CSS need not always use the first one in the list. It doesn't have to use it at all. All I want to say is that if the CSS needs to get an authorization token (from a cache or service) it will be indicated by the first element, and that first element is sufficient to get all the information that is needed for the target. That if the target works at all for the client, it must work off of information based solely on the CSS's interpretation of the first element, guarrenteeing interoperability with clients that ignore any others he puts there. I will grant you an update on my first sentence adding the "zero or more elements", and the more "positive" tone on selecting the first element. That was a screw up on my part. -------- The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. Should the sequence contain more than one element, the CSS shall use only the first element in determining the AuthorizationToken to be delivered. The syntax field .... --------- Cheers, -Polar > > As such, a CSS may choose to reject a request that comes with > > multiple ServiceConfiguration elements, in which case they > > should document the fact that the implementation rejects > > requests that come with more than one ServiceConfiguration > > element." Inclusion of this would allow the creation of OSSs > > that strictly do not accept additional ServiceConfiguration > > elements, while allowing for implementations that do. > > > > We could also add a clarifying footnote or some such, which > > says something like "For a CSS to meaningfully process any > > ServiceConfiguration elements other than the first, there must > > be an out of band agreement in place between the client OSS and > > the server OSS defining the semantics of such usage, since this > > standard does not ascribe any specific meaning to such usage. > > This option is included mostly to enable experimental use, > > without forcing such experimental implementations into becoming > > non-conformant." > > I look forward to comments... > > -DMC > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Mon, 16 Apr 2001 11:24:12 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL, Florham Park NJ USA X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: p*+e9YQFe9#SDe9Z&>!! Polar Humenn wrote: > > On Fri, 13 Apr 2001, David Chizmadia wrote: > > Polar wrote: > > > The privilege_authorities field contains a sequence of > > > ServiceConfiguration. A non-empty sequence indicates that the target > > > supports the CSS delivery of an AuthorizationToken, which is delivered in > > > the EstablishContext message. Should the sequence contain more than one > > > element, the CSS shall ignore all, but the first one. The syntax field > > > .... > > > > Although not quite as concise as Polar's proposal above, I would like to > > suggest the following: > > > > [1] replace paragraph 148 with the following paragraph > > > > The privilege_authorities field contains a sequence of 0 or more > > ServiceConfiguration elements, each representing a valid privilege > > authority. The CSS shall always use the authority named in the first > > ServiceConfiguration element of a non-empty privilege_authorities field to > > acquire the AuthorizationElements it uses in its EstablishContext message. > > It it recommended that a CSS reject a request that comes with multiple > > ServiceConfiguration elements by raising an exception. {We'll > > need to identify the appropriate exception.} > > > > [footnote] > > For a CSS to acquire and reconcile AuthorizationElements acquired from > > authorities named in any additional ServiceConfiguration elements in the > > privilege_authorities field, there must be an out of band agreement in place > > between the client OSS and the server OSS defining the semantics of such > > usage, since this standard does not do so. This option is included mostly > > to enable experimental use of multiple privilege authorities, without > > forcing such experimental implementations into becoming non-conformant. > > > > > > I think that this paragraph, plus the footnote, captures the effect of > > Jishnu's suggestions below, while reversing their sense to reflect what (I > > think) Polar (and I) have been advocating should be "standard" CSIv2 > > behavior. Actually, as you both should have guessed by now, I do not disagree with you on what the standard behavior is. I just worry about whether a bridge (see below) gets knocked out of conformance due to the wording that we are proposing to use. > David, > > This is a litte over the top. I really don't think it is necessary > to > "recommend that a CSS reject a request...". Recommedations that > aren't > mandated in this field are really meaningless, and probably > confusing. > > And also, that is not the behavior these guys want. They always want > to > deal with the first one. So, give it to them. The others are outside > of > the specification. I have no idea who the "they" might be.:-) I was just talking for myself. Very hard for me to figure out what anybody else actually wants.:-) I am just trying to make sure that it is possible to build bridges between a pure CSIv2 domain and a CSIv2 + extensions domain without having the bridge run afoul of the CSIv2 conformance requirements (see below). > Second of all, the CSS need not always use the first one in the list. It > doesn't have to use it at all. That is correct. > All I want to say is that if the CSS needs to get an authorization token > (from a cache or service) it will be indicated by the first element, and > that first element is sufficient to get all the information that is needed > for the target. That if the target works at all for the client, it must > work off of information based solely on the CSS's interpretation of the > first element, guarrenteeing interoperability with clients that ignore any > others he puts there. > > I will grant you an update on my first sentence adding the "zero or more > elements", and the more "positive" tone on selecting the first > element. That was a screw up on my part. > > -------- > > The privilege_authorities field contains a sequence of zero or more > ServiceConfiguration elements. A non-empty sequence indicates that the > target supports the CSS delivery of an AuthorizationToken, which is > delivered in the EstablishContext message. Should the sequence contain > more than one element, the CSS shall use only the first element in > determining the AuthorizationToken to be delivered. The syntax field .... OK, I think we are getting close. Let me mention one slight concern that I have and if that is taken care of I will be happy. Consider the case of a CSS that is acting as a bridge between a CSIv2 compliant domain, and a CSIv2 + extensions as in multiple elements domain. Will the fact that while processing messages coming from the CSIv2 + extensions domain, the CSS looks at more than the first element render it non-compliant for the purposes of claiming compliance to CSIv2? Note that while processing messages from the CSIv2 domain it does exactly what is stated in the standard. The question is does the word "only" in the last sentence above render this bridge CSS non-compliant (I should think not, but there is a possibility that the statement as written above could be interpreted that way). If so, then I think we need to say something to make sure that such a bridge is still compliant as long as it behaves properly with the CSIv2 domain. Perhaps a wording of the last sentence using the language from Polars explantion of what he wants a few paragraphs up in the excerpted text from his message, actually does the trick. How about if we say something like: "Should the sequence contain more than one element, the first element shall contain sufficient information for the CSS to determine the AuthorizationToken to be delivered." This is just a thought, not a final proposal. I would like to maintain the succinctness of Polar's language and yet, avoid inadvertent over-restriction of conformance. I hope you see where I am coming from and that I do not disagree with the basic premise of what constitutes the basic conformance requirement for CSIv2. Thanks, Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 16 Apr 2001 12:16:14 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: David Chizmadia , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types In-Reply-To: <3ADB0E9B.A6253372@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 75!!!DL=!!]*'!!'-,e9 On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > Polar Humenn wrote: > > > > On Fri, 13 Apr 2001, David Chizmadia wrote: > > > > Polar wrote: > > > > The privilege_authorities field contains a sequence of > > > > ServiceConfiguration. A non-empty sequence indicates that the target > > > > supports the CSS delivery of an AuthorizationToken, which is delivered in > > > > the EstablishContext message. Should the sequence contain more than one > > > > element, the CSS shall ignore all, but the first one. The syntax field > > > > .... > > > > > > Although not quite as concise as Polar's proposal above, I would like to > > > suggest the following: > > > > > > [1] replace paragraph 148 with the following paragraph > > > > > > The privilege_authorities field contains a sequence of 0 or more > > > ServiceConfiguration elements, each representing a valid privilege > > > authority. The CSS shall always use the authority named in the first > > > ServiceConfiguration element of a non-empty privilege_authorities field to > > > acquire the AuthorizationElements it uses in its EstablishContext message. > > > It it recommended that a CSS reject a request that comes with multiple > > > ServiceConfiguration elements by raising an exception. {We'll > > > need to identify the appropriate exception.} > > > > > > [footnote] > > > For a CSS to acquire and reconcile AuthorizationElements acquired from > > > authorities named in any additional ServiceConfiguration elements in the > > > privilege_authorities field, there must be an out of band agreement in place > > > between the client OSS and the server OSS defining the semantics of such > > > usage, since this standard does not do so. This option is included mostly > > > to enable experimental use of multiple privilege authorities, without > > > forcing such experimental implementations into becoming non-conformant. > > > > > > > > > I think that this paragraph, plus the footnote, captures the effect of > > > Jishnu's suggestions below, while reversing their sense to reflect what (I > > > think) Polar (and I) have been advocating should be "standard" CSIv2 > > > behavior. > > Actually, as you both should have guessed by now, I do not disagree with > you on what the standard behavior is. I just worry about whether a > bridge (see below) gets knocked out of conformance due to the wording > that we are proposing to use. > > > David, > > > > This is a litte over the top. I really don't think it is necessary to > > "recommend that a CSS reject a request...". Recommedations that aren't > > mandated in this field are really meaningless, and probably confusing. > > > > And also, that is not the behavior these guys want. They always want to > > deal with the first one. So, give it to them. The others are outside of > > the specification. > > I have no idea who the "they" might be.:-) I was just talking for > myself. Very hard for me to figure out what anybody else actually > wants.:-) I am just trying to make sure that it is possible to build > bridges between a pure CSIv2 domain and a CSIv2 + extensions domain > without having the bridge run afoul of the CSIv2 conformance > requirements (see below). > > > Second of all, the CSS need not always use the first one in the list. It > > doesn't have to use it at all. > > That is correct. > > > All I want to say is that if the CSS needs to get an authorization token > > (from a cache or service) it will be indicated by the first element, and > > that first element is sufficient to get all the information that is needed > > for the target. That if the target works at all for the client, it must > > work off of information based solely on the CSS's interpretation of the > > first element, guarrenteeing interoperability with clients that ignore any > > others he puts there. > > > > I will grant you an update on my first sentence adding the "zero or more > > elements", and the more "positive" tone on selecting the first > > element. That was a screw up on my part. > > > > -------- > > > > The privilege_authorities field contains a sequence of zero or more > > ServiceConfiguration elements. A non-empty sequence indicates that the > > target supports the CSS delivery of an AuthorizationToken, which is > > delivered in the EstablishContext message. Should the sequence contain > > more than one element, the CSS shall use only the first element in > > determining the AuthorizationToken to be delivered. The syntax field .... > > OK, I think we are getting close. > > Let me mention one slight concern that I have and if that is taken care > of I will be happy. Consider the case of a CSS that is acting as a > bridge between a CSIv2 compliant domain, and a CSIv2 + extensions as in > multiple elements domain. Will the fact that while processing messages > coming from the CSIv2 + extensions domain, the CSS looks at more than > the first element render it non-compliant for the purposes of claiming > compliance to CSIv2? Note that while processing messages from the CSIv2 > domain it does exactly what is stated in the standard. The question is > does the word "only" in the last sentence above render this bridge CSS > non-compliant (I should think not, but there is a possibility that the > statement as written above could be interpreted that way). If so, then I > think we need to say something to make sure that such a bridge is still > compliant as long as it behaves properly with the CSIv2 domain. Well I don't really mind your approach, but I have reservations about your notion of "compliance". I don't know how the description above would be really "compliant" to anything. To be "compliant" in the positive sense it would have to "comply" to something. If it wants to do anything else but look at the first one, to what is it complying? There is no specification. The fact that it does anything else puts it outside of the protocol. But I doubt that it would make it "uncompliant" to CSIv2 in a sense, since it really doesn't have to look at anything to send the target an authorization token to "operate" the protocol. (The target is not even required to reject it, if doesn't put one in the IOR). But, what does compliance mean in this sense? Are you worried about technical compliance or marketing compliance? > Perhaps a wording of the last sentence using the language from Polars > explantion of what he wants a few paragraphs up in the excerpted text > from his message, actually does the trick. How about if we say something > like: > > "Should the sequence contain more than one element, the first element > shall contain sufficient information for the CSS to determine the > AuthorizationToken to be delivered." I don't mind this as it puts a requirement on the TSS to actually supply a description that can obviate the others. However, I don't think it drives the point home. How about adding the following sentence. "All subsequent elements may be ignored by the CSS in making this determination". But there are no "shalls", so I'm not sure if it really has any meaningful effect. It's just a clarification that a CSS is not required to look at anything but the first one. So how about: "Should the sequence contain more than one element, a CSS shall not be required to look beyond the first element of this sequence in determining the AuthorizationToken to be delivered. Cheers, -Polar > This is just a thought, not a final proposal. I would like to maintain > the succinctness of Polar's language and yet, avoid inadvertent > over-restriction of conformance. I hope you see where I am coming from > and that I do not disagree with the basic premise of what constitutes > the basic conformance requirement for CSIv2. > > Thanks, > > Jishnu. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types Date: Mon, 16 Apr 2001 14:39:17 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: )9X!!n^\d9o%Q!!#9J!! Polar Humenn wrote: > Well I don't really mind your approach, but I have reservations about > your notion of "compliance". > > I don't know how the description above would be really "compliant" to > anything. To be "compliant" in the positive sense it would have to > "comply" to something. If it wants to do anything else but look at the > first one, to what is it complying? There is no specification. > > The fact that it does anything else puts it outside of the protocol. But I > doubt that it would make it "uncompliant" to CSIv2 in a sense, since it > really doesn't have to look at anything to send the target an > authorization token to "operate" the protocol. (The target is not even > required to reject it, if doesn't put one in the IOR). > > But, what does compliance mean in this sense? Are you worried about > technical compliance or marketing compliance? > > > Perhaps a wording of the last sentence using the language from Polars > > explantion of what he wants a few paragraphs up in the excerpted text > > from his message, actually does the trick. How about if we say something > > like: > > > > "Should the sequence contain more than one element, the first element > > shall contain sufficient information for the CSS to determine the > > AuthorizationToken to be delivered." > > I don't mind this as it puts a requirement on the TSS to actually supply > a description that can obviate the others. However, I don't think it > drives the point home. How about adding the following sentence. > > "All subsequent elements may be ignored by the CSS in making this > determination". > > But there are no "shalls", so I'm not sure if it really has any meaningful > effect. It's just a clarification that a CSS is not required to look at > anything but the first one. > > So how about: > > "Should the sequence contain more than one element, a CSS shall not be > required to look beyond the first element of this sequence in determining > the AuthorizationToken to be delivered. > > Cheers, > -Polar Polar, As a matter of style, I prefer to avoid conditionals in statements. Does the sentence below reflect your intent? "It shall be possible for the CSS to construct an AuthorizationToken that is acceptable to the TSS using only the privilege authority referenced by the first element of the sequence." All, In its full context, the revised wording for para 148 would look something like: "The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken in the EstablishContext message. It shall be possible for the CSS to construct an AuthorizationToken that is acceptable to the target using only the privilege authority referenced by the first element of the sequence. The syntax field ..." Comments welcomed :-) -DMC Date: Mon, 16 Apr 2001 15:40:58 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1+'e9gRd!!\%e!!j6,e9 Polar Humenn wrote: > Jishnu wrote > > Polar wrote > > > The privilege_authorities field contains a sequence of zero or more > > > ServiceConfiguration elements. A non-empty sequence indicates that the > > > target supports the CSS delivery of an AuthorizationToken, which is > > > delivered in the EstablishContext message. Should the sequence contain > > > more than one element, the CSS shall use only the first element in > > > determining the AuthorizationToken to be delivered. The syntax field .... > > > > OK, I think we are getting close. > > > > Let me mention one slight concern that I have and if that is taken care > > of I will be happy. Consider the case of a CSS that is acting as a > > bridge between a CSIv2 compliant domain, and a CSIv2 + extensions as in > > multiple elements domain. Will the fact that while processing messages > > coming from the CSIv2 + extensions domain, the CSS looks at more than > > the first element render it non-compliant for the purposes of claiming > > compliance to CSIv2? Note that while processing messages from the CSIv2 > > domain it does exactly what is stated in the standard. The question is > > does the word "only" in the last sentence above render this bridge CSS > > non-compliant (I should think not, but there is a possibility that the > > statement as written above could be interpreted that way). If so, then I > > think we need to say something to make sure that such a bridge is still > > compliant as long as it behaves properly with the CSIv2 domain. > > Well I don't really mind your approach, but I have reservations about > your notion of "compliance". You are correct in having reservations, because it depends on what criteria are used to determine compliance. you could just do a black box test, or at an extreme it could involve code reading. I am just trying to cover bases in the middle somewhere. > > > I don't know how the description above would be really "compliant" >to > anything. To be "compliant" in the positive sense it would have to > "comply" to something. If it wants to do anything else but look at >the > first one, to what is it complying? There is no specification. > > The fact that it does anything else puts it outside of the >protocol. But I > doubt that it would make it "uncompliant" to CSIv2 in a sense, since >it > really doesn't have to look at anything to send the target an > authorization token to "operate" the protocol. (The target is not >even > required to reject it, if doesn't put one in the IOR). > > But, what does compliance mean in this sense? Are you worried about > technical compliance or marketing compliance? Well, since OMG does not do any compliance test of any sort, perhaps I should not worry at all. But, usually, these things come up in arguments with a vendor about the behavior of their code relative to a standard. I understand the intent having been party to this discussion. But when some techno-marketing green ho9rn reads the standard and tries to interpret the standard in ways that makes life easier for them as per their perception, I want to make sure that they have to stretch credulity to arrive at a meaning that we did not intend, that's pretty much it > > Perhaps a wording of the last sentence using the language from Polars > > explantion of what he wants a few paragraphs up in the excerpted text > > from his message, actually does the trick. How about if we say something > > like: > > > > "Should the sequence contain more than one element, the first element > > shall contain sufficient information for the CSS to determine the > > AuthorizationToken to be delivered." > > I don't mind this as it puts a requirement on the TSS to actually supply > a description that can obviate the others. However, I don't think it > drives the point home. How about adding the following sentence. > > "All subsequent elements may be ignored by the CSS in making this > determination". > > But there are no "shalls", so I'm not sure if it really has any meaningful > effect. It's just a clarification that a CSS is not required to look at > anything but the first one. > > So how about: > > "Should the sequence contain more than one element, a CSS shall not be > required to look beyond the first element of this sequence in determining > the AuthorizationToken to be delivered. I am happy with that. I think that addresses the concern I had adequately. So putting it all together, the full proposed resolution then should read: Proposed Resolution: [1] replace paragraph 148 with the following paragraph The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. Should the sequence contain more than one element, a CSS shall not be required to look beyond the first element of this sequence in determining the AuthorizationToken to be delivered. The syntax field within the ServiceConfiguration element identifies the format used to represent the authority. Two alternative formats are currently defined: an ASN.1 encoding of the GeneralNames (as defined in [IETF RFC 2459]) which identify a privilege authority, or a GSS exported name (as defined in [IETF RFC 2743] Section 3.2) encoding of the name of a privilege authority." _______________________________________________________ How's that? Just received David's suggestion. I am also OK with: "The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken in the EstablishContext message. It shall be possible for the CSS to construct an AuthorizationToken that is acceptable to the target using only the privilege authority referenced by the first element of the sequence." as the first paragraph in the above, as long as there are no confusion about what "acceptable" means in determining the fact of a CSS being unable to construct a AuthorizationToken that is "acceptable" It opens up opportunities for interpreting "acceptable" in innovative ways.:-) Well, since Dave does not like conditionals, why not just remove that from Polar's suggested text and say: "The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. A CSS shall not be required to look beyond the first element of this sequence in determining the AuthorizationToken to be delivered." I think it holds together in that form, no? Thanks. Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 16 Apr 2001 15:32:46 -0400 (EDT) From: Polar Humenn To: Jishnu Mukerji cc: David Chizmadia , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types In-Reply-To: <3ADB4ACA.B956646@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: L1$e9Z:i!!!C*e98X?!! On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > How's that? > > Just received David's suggestion. I am also OK with: > > "The privilege_authorities field contains a sequence of zero or more > ServiceConfiguration elements. A non-empty sequence indicates that >the > target supports the CSS delivery of an AuthorizationToken in the > EstablishContext message. It shall be possible for the CSS to >construct an > AuthorizationToken that is acceptable to the target using only the >privilege > authority referenced by the first element of the sequence." > > as the first paragraph in the above, as long as there are no >confusion > about what "acceptable" means in determining the fact of a CSS > being unable to construct a AuthorizationToken that is "acceptable" > It opens up opportunities for interpreting "acceptable" in >innovative > ways.:-) I whole heartily agree. The term "acceptable" begs the question. > Well, since Dave does not like conditionals, why not just remove that from Polar's > suggested text and say: > > "The privilege_authorities field contains a sequence of zero or more > ServiceConfiguration elements. A non-empty sequence indicates that the > target supports the CSS delivery of an AuthorizationToken, which is > delivered in the EstablishContext message. A CSS shall not be required > to look beyond the first element of this sequence in determining the > AuthorizationToken to be delivered." > > I think it holds together in that form, no? Yes, I believe it does. I will be okay with the phrasing above. I'm not sure if it was intentional on your part, but I think spliting the paragraph into two parts - the above, and the second starting with "The syntax field..." is a good idea. Cheers, -Polar > > Thanks. > > Jishnu. > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com From: Jeffrey Mischkinsky Message-Id: <200104162007.NAA05491@wheel.dcn.davis.ca.us> Subject: Re: Proposed resolution to issue 4118: Multiple Privilege To: jishnu_mukerji@hp.com Date: Mon, 16 Apr 2001 13:07:54 -0700 (PDT) Cc: polar@adiron.com (Polar Humenn), dchizmadia@promia.com (David Chizmadia), csiv2-ftf@omg.org In-Reply-To: <3ADB4ACA.B956646@hp.com> from "Jishnu Mukerji" at Apr 16, 2001 03:40:58 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Sjjd9*M'e9`h2e935(e9 'Jishnu Mukerji' writes: > suggested text and say: > > "The privilege_authorities field contains a sequence of zero or more > ServiceConfiguration elements. A non-empty sequence indicates that the > target supports the CSS delivery of an AuthorizationToken, which is > delivered in the EstablishContext message. A CSS shall not be required > to look beyond the first element of this sequence in determining the > AuthorizationToken to be delivered." > > I think it holds together in that form, no? works for me. The implication that i would take from the above is: When i receive a giop message which contains Serviceconfg elements, I have to be prepared to parse/accept any number (i.e. i can't throw some sort of protocol error becuase there are 10 of them), but i can throw away all but the first if that's what i choose to do. I can also choose to provide a different interpretation of the first, based upon info i find in latter ones. I.E i might get a different answer if i proccess just the first one, or if i process the first one in the context of what comes later. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* Date: Mon, 16 Apr 2001 16:28:17 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky Cc: Polar Humenn , David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege References: <200104162007.NAA05491@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b2\!!^Z\!!-P`d9~1nd9 Jeffrey Mischkinsky wrote: > 'Jishnu Mukerji' writes: > > suggested text and say: > > > > "The privilege_authorities field contains a sequence of zero or more > > ServiceConfiguration elements. A non-empty sequence indicates that the > > target supports the CSS delivery of an AuthorizationToken, which is > > delivered in the EstablishContext message. A CSS shall not be required > > to look beyond the first element of this sequence in determining the > > AuthorizationToken to be delivered." > > > > I think it holds together in that form, no? > > works for me. > > The implication that i would take from the above is: > When i receive a giop message which contains Serviceconfg elements, I > have to be prepared to parse/accept any number (i.e. i can't throw > some sort of protocol error becuase there are 10 of them), but i can > throw away all but the first if that's what i choose to do. Yes, and you would be fully within your rights to do so without becoming non-compliant. > I can also choose to provide a different interpretation of the first, > based upon info i find in latter ones. I.E i might get a different > answer if i proccess just the first one, or if i process the first > one in the context of what comes later. However, in my understanding, that different interpretation involving additional elements would be subject of an out of band agreement, so strictly speaking such a different interpretation is outside the scope of the standard. Once you are outside the standard, of course you can get whatever interpretation you dream up. Jishnu. Date: Mon, 16 Apr 2001 16:31:08 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn Cc: David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )5B!!'8$e9 On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > > > Just received David's suggestion. I am also OK with: > > > > "The privilege_authorities field contains a sequence of zero or >more > > ServiceConfiguration elements. A non-empty sequence indicates that >the > > target supports the CSS delivery of an AuthorizationToken in the > > EstablishContext message. It shall be possible for the CSS to >construct an > > AuthorizationToken that is acceptable to the target using only the >privilege > > authority referenced by the first element of the sequence." > > > > as the first paragraph in the above, as long as there are no >confusion > > about what "acceptable" means in determining the fact of a CSS > > being unable to construct a AuthorizationToken that is >"acceptable" > > It opens up opportunities for interpreting "acceptable" in >innovative > > ways.:-) > > I whole heartily agree. The term "acceptable" begs the question. > > > Well, since Dave does not like conditionals, why not just remove >that from Polar's > > suggested text and say: > > > > "The privilege_authorities field contains a sequence of zero or >more > > ServiceConfiguration elements. A non-empty sequence indicates that >the > > target supports the CSS delivery of an AuthorizationToken, which >is > > delivered in the EstablishContext message. A CSS shall not be >required > > to look beyond the first element of this sequence in determining >the > > AuthorizationToken to be delivered." > > > > I think it holds together in that form, no? > > Yes, I believe it does. I will be okay with the phrasing above. Good, so we finally have an agreement. Now I hope Ron is OK with this. > > I'm not sure if it was intentional on your part, but I think >spliting the > paragraph into two parts - the above, and the second starting with >"The > syntax field..." is a good idea. Why Thank you.:-) The two pargraphs appeared to be talking about slightly different things. Besides we were trying to settle the content of the first paragraph, and not the second, seemed like a good reason to separate them out. Cheers, Jishnu. From: Jeffrey Mischkinsky Message-Id: <200104162029.NAA07744@wheel.dcn.davis.ca.us> Subject: Re: Proposed resolution to issue 4118: Multiple Privilege To: jishnu_mukerji@hp.com Date: Mon, 16 Apr 2001 13:29:46 -0700 (PDT) Cc: polar@adiron.com (Polar Humenn), dchizmadia@promia.com (David Chizmadia), csiv2-ftf@omg.org In-Reply-To: <3ADB55E1.BF09BA82@hp.com> from "Jishnu Mukerji" at Apr 16, 2001 04:28:17 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: *kKe91)P!!N@F!!(CY!! 'Jishnu Mukerji' writes: > > > > Jeffrey Mischkinsky wrote: > > > 'Jishnu Mukerji' writes: > > > suggested text and say: > > > > > > "The privilege_authorities field contains a sequence of zero or more > > > ServiceConfiguration elements. A non-empty sequence indicates that the > > > target supports the CSS delivery of an AuthorizationToken, which is > > > delivered in the EstablishContext message. A CSS shall not be required > > > to look beyond the first element of this sequence in determining the > > > AuthorizationToken to be delivered." > > > > > > I think it holds together in that form, no? > > > > works for me. > > > > The implication that i would take from the above is: > > When i receive a giop message which contains Serviceconfg elements, I > > have to be prepared to parse/accept any number (i.e. i can't throw > > some sort of protocol error becuase there are 10 of them), but i can > > throw away all but the first if that's what i choose to do. > > Yes, and you would be fully within your rights to do so without becoming > non-compliant. > > > I can also choose to provide a different interpretation of the first, > > based upon info i find in latter ones. I.E i might get a different > > answer if i proccess just the first one, or if i process the first > > one in the context of what comes later. > > However, in my understanding, that different interpretation involving > additional elements would be subject of an out of band agreement, so > strictly speaking such a different interpretation is outside the scope of > the standard. Once you are outside the standard, of course you can get > whatever interpretation you dream up. yup. And hence such "interesting" behavior would mean that i am exhibiting non-conformant behavior and such an implementation should fail a well written conformance test. jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* Reply-To: "David Chizmadia" From: "David Chizmadia" To: References: Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types Date: Mon, 16 Apr 2001 16:35:43 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ZW^!!c:a!!-J`d9YU/e9 Comments in line - basically agree! -DMC ----- Original Message ----- From: "Polar Humenn" To: "Jishnu Mukerji" Cc: "David Chizmadia" ; Sent: Monday, April 16, 2001 3:32 PM Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types > On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > > > How's that? > > > > Just received David's suggestion. I am also OK with: > > > > "The privilege_authorities field contains a sequence of zero or >more > > ServiceConfiguration elements. A non-empty sequence indicates that >the > > target supports the CSS delivery of an AuthorizationToken in the > > EstablishContext message. It shall be possible for the CSS to >construct an > > AuthorizationToken that is acceptable to the target using only the privilege > > authority referenced by the first element of the sequence." > > > > as the first paragraph in the above, as long as there are no >confusion > > about what "acceptable" means in determining the fact of a CSS > > being unable to construct a AuthorizationToken that is >"acceptable" > > It opens up opportunities for interpreting "acceptable" in >innovative > > ways.:-) > > I whole heartily agree. The term "acceptable" begs the question. Sorry for the oversight - I should have written "AuthorizationToken that the target will recognize as valid" rather than "AuthorizationToken that is acceptable to the target". > > > Well, since Dave does not like conditionals, why not just remove that from Polar's > > suggested text and say: > > > > "The privilege_authorities field contains a sequence of zero or more > > ServiceConfiguration elements. A non-empty sequence indicates that the > > target supports the CSS delivery of an AuthorizationToken, which is > > delivered in the EstablishContext message. A CSS shall not be required > > to look beyond the first element of this sequence in determining the > > AuthorizationToken to be delivered." > > > > I think it holds together in that form, no? > > > Yes, I believe it does. I will be okay with the phrasing above. The second sentence doesn't need ", which is delivered". I personally consider "look beyond" to be too imprecise. On the other hand, I can't conceive of any changes that don't involve wording that was discarded several messages ago. If the consensus goes against my revised wording above, I'll stand behind this wording. > > I'm not sure if it was intentional on your part, but I think >spliting the > paragraph into two parts - the above, and the second starting with >"The > syntax field..." is a good idea. I also liked the separated paragraph. > > > Cheers, > -Polar > -DMC Date: Mon, 16 Apr 2001 16:47:30 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky Cc: Polar Humenn , David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege References: <200104162029.NAA07744@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: //Wd9WdPe9\Jjd9VBO!! Jeffrey Mischkinsky wrote: > 'Jishnu Mukerji' writes: > > > > > > > > Jeffrey Mischkinsky wrote: > > > > > 'Jishnu Mukerji' writes: > > > > suggested text and say: > > > > > > > > "The privilege_authorities field contains a sequence of zero or more > > > > ServiceConfiguration elements. A non-empty sequence indicates that the > > > > target supports the CSS delivery of an AuthorizationToken, which is > > > > delivered in the EstablishContext message. A CSS shall not be required > > > > to look beyond the first element of this sequence in determining the > > > > AuthorizationToken to be delivered." > > > > > > > > I think it holds together in that form, no? > > > > > > works for me. > > > > > > The implication that i would take from the above is: > > > When i receive a giop message which contains Serviceconfg elements, I > > > have to be prepared to parse/accept any number (i.e. i can't throw > > > some sort of protocol error becuase there are 10 of them), but i can > > > throw away all but the first if that's what i choose to do. > > > > Yes, and you would be fully within your rights to do so without becoming > > non-compliant. > > > > > I can also choose to provide a different interpretation of the first, > > > based upon info i find in latter ones. I.E i might get a different > > > answer if i proccess just the first one, or if i process the first > > > one in the context of what comes later. > > > > However, in my understanding, that different interpretation involving > > additional elements would be subject of an out of band agreement, so > > strictly speaking such a different interpretation is outside the scope of > > the standard. Once you are outside the standard, of course you can get > > whatever interpretation you dream up. > yup. > And hence such "interesting" behavior would mean that i am exhibiting > non-conformant behavior and such an implementation should fail a well > written conformance test. Indeed. Those would be the experimental extensions which my original footnote alluded to, and they should fail carefully written conformance tests. Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Mon, 16 Apr 2001 17:50:54 -0400 (EDT) From: Polar Humenn To: David Chizmadia cc: Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types In-Reply-To: <004a01c0c6b4$d1720f60$a000a8c0@davidch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: !)He9\D Comments in line - basically agree! -DMC > > ----- Original Message ----- > From: "Polar Humenn" > To: "Jishnu Mukerji" > Cc: "David Chizmadia" ; > Sent: Monday, April 16, 2001 3:32 PM > Subject: Re: Proposed resolution to issue 4118: Multiple Privilege > AuthoritiesandSupported Naming Types > > > > On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > > > > > How's that? > > > > > > Just received David's suggestion. I am also OK with: > > > > > > "The privilege_authorities field contains a sequence of zero or >more > > > ServiceConfiguration elements. A non-empty sequence indicates >that the > > > target supports the CSS delivery of an AuthorizationToken in the > > > EstablishContext message. It shall be possible for the CSS to >construct > an > > > AuthorizationToken that is acceptable to the target using only >the > privilege > > > authority referenced by the first element of the sequence." > > > > > > as the first paragraph in the above, as long as there are no >confusion > > > about what "acceptable" means in determining the fact of a CSS > > > being unable to construct a AuthorizationToken that is >"acceptable" > > > It opens up opportunities for interpreting "acceptable" in >innovative > > > ways.:-) > > > > I whole heartily agree. The term "acceptable" begs the question. > > Sorry for the oversight - I should have written "AuthorizationToken >that the > target will recognize as valid" rather than "AuthorizationToken that >is > acceptable to the target". > > > > > > Well, since Dave does not like conditionals, why not just remove >that > from Polar's > > > suggested text and say: > > > > > > "The privilege_authorities field contains a sequence of zero or >more > > > ServiceConfiguration elements. A non-empty sequence indicates >that the > > > target supports the CSS delivery of an AuthorizationToken, which >is > > > delivered in the EstablishContext message. A CSS shall not be >required > > > to look beyond the first element of this sequence in determining >the > > > AuthorizationToken to be delivered." > > > > > > I think it holds together in that form, no? > > > > > > Yes, I believe it does. I will be okay with the phrasing above. > > The second sentence doesn't need ", which is delivered". Oh well, true, almost any phrase properly worded as ", which ..." doesn't really need to be there. It is a clarification. I think this "which" clause clarifies where the AuthorizationToken is delivered, i.e. in the EstablishContext message. Although, we are not really talking about anything else but this CSIv2 protocol, authorization tokens can coneivably be delivered by other means. For instance, the CSS may deliver an AuthorizationToken to the target's ATLAS for translation, and this delivery happens in the GIOP argument stream. Cheers, -Polar > I personally consider "look beyond" to be too imprecise. On the other hand, > I can't conceive of any changes that don't involve wording that was > discarded several messages ago. If the consensus goes against my revised > wording above, I'll stand behind this wording. > > > > > I'm not sure if it was intentional on your part, but I think spliting the > > paragraph into two parts - the above, and the second starting with "The > > syntax field..." is a good idea. > > I also liked the separated paragraph. > > > > > > > Cheers, > > -Polar > > > > -DMC > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 17 Apr 2001 16:19:37 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jishnu_mukerji@hp.com CC: Polar Humenn , David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: <3ADB568C.2E0AAD34@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ``?e9V > Polar Humenn wrote: > > > On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > > > > > Just received David's suggestion. I am also OK with: > > > > > > "The privilege_authorities field contains a sequence of zero or more > > > ServiceConfiguration elements. A non-empty sequence indicates that the > > > target supports the CSS delivery of an AuthorizationToken in the > > > EstablishContext message. It shall be possible for the CSS to construct an > > > AuthorizationToken that is acceptable to the target using only the privilege > > > authority referenced by the first element of the sequence." > > > > > > as the first paragraph in the above, as long as there are no confusion > > > about what "acceptable" means in determining the fact of a CSS > > > being unable to construct a AuthorizationToken that is "acceptable" > > > It opens up opportunities for interpreting "acceptable" in innovative > > > ways.:-) > > > > I whole heartily agree. The term "acceptable" begs the question. > > > > > Well, since Dave does not like conditionals, why not just remove that from Polar's > > > suggested text and say: > > > > > > "The privilege_authorities field contains a sequence of zero or more > > > ServiceConfiguration elements. A non-empty sequence indicates that the > > > target supports the CSS delivery of an AuthorizationToken, which is > > > delivered in the EstablishContext message. A CSS shall not be required > > > to look beyond the first element of this sequence in determining the > > > AuthorizationToken to be delivered." > > > > > > I think it holds together in that form, no? > > > > Yes, I believe it does. I will be okay with the phrasing above. > > Good, so we finally have an agreement. Now I hope Ron is OK with this. I think the current form is "The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. A CSS shall not be required to look beyond the first element of this sequence in determining the AuthorizationToken to be delivered." and David has proposed that the ", which is delivered" phrase be removed. I will support the following (including the removal of the ", which is delivered" if you desire): "The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. The first element of the privilege_authorities field shall define the AuthorizationToken to be delivered." Ron > > > > > I'm not sure if it was intentional on your part, but I think spliting the > > paragraph into two parts - the above, and the second starting with "The > > syntax field..." is a good idea. > > Why Thank you.:-) The two pargraphs appeared to be talking about slightly different > things. Besides we were trying to settle the content of the first paragraph, and not the > second, seemed like a good reason to separate them out. > > Cheers, > > Jishnu. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Apr 2001 11:34:11 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: , David Chizmadia , Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types In-Reply-To: <3ADCA559.F495C411@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: B`i!!E^[!!2]Rd9Z7G!! On Tue, 17 Apr 2001, Ron Monzillo wrote: > > > Jishnu Mukerji wrote: > > > > Polar Humenn wrote: > > > > > On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > > > > > > > Just received David's suggestion. I am also OK with: > > > > > > > > "The privilege_authorities field contains a sequence of zero >or more > > > > ServiceConfiguration elements. A non-empty sequence indicates >that the > > > > target supports the CSS delivery of an AuthorizationToken in >the > > > > EstablishContext message. It shall be possible for the CSS to >construct an > > > > AuthorizationToken that is acceptable to the target using only >the privilege > > > > authority referenced by the first element of the sequence." > > > > > > > > as the first paragraph in the above, as long as there are no >confusion > > > > about what "acceptable" means in determining the fact of a CSS > > > > being unable to construct a AuthorizationToken that is >"acceptable" > > > > It opens up opportunities for interpreting "acceptable" in >innovative > > > > ways.:-) > > > > > > I whole heartily agree. The term "acceptable" begs the question. > > > > > > > Well, since Dave does not like conditionals, why not just >remove that from Polar's > > > > suggested text and say: > > > > > > > > "The privilege_authorities field contains a sequence of zero >or more > > > > ServiceConfiguration elements. A non-empty sequence indicates >that the > > > > target supports the CSS delivery of an AuthorizationToken, >which is > > > > delivered in the EstablishContext message. A CSS shall not be >required > > > > to look beyond the first element of this sequence in >determining the > > > > AuthorizationToken to be delivered." > > > > > > > > I think it holds together in that form, no? > > > > > > Yes, I believe it does. I will be okay with the phrasing above. > > > > Good, so we finally have an agreement. Now I hope Ron is OK with >this. > > I think the current form is > > "The privilege_authorities field contains a sequence of zero or more > ServiceConfiguration elements. A non-empty sequence indicates that >the > target supports the CSS delivery of an AuthorizationToken, which is > delivered in the EstablishContext message. A CSS shall not be >required > to look beyond the first element of this sequence in determining the > AuthorizationToken to be delivered." > > and David has proposed that the ", which is delivered" phrase be > removed. I will support the following (including the removal of the >", > which is delivered" if you desire): > > "The privilege_authorities field contains a sequence of zero or more > ServiceConfiguration elements. A non-empty sequence indicates that >the > target supports the CSS delivery of an AuthorizationToken, which is > delivered in the EstablishContext message. The first element of the > privilege_authorities field shall define the AuthorizationToken to >be > delivered." What does "define" mean? -Polar > Ron > > > > > > > > > I'm not sure if it was intentional on your part, but I think >spliting the > > > paragraph into two parts - the above, and the second starting >with "The > > > syntax field..." is a good idea. > > > > Why Thank you.:-) The two pargraphs appeared to be talking about >slightly different > > things. Besides we were trying to settle the content of the first >paragraph, and not the > > second, seemed like a good reason to separate them out. > > > > Cheers, > > > > Jishnu. > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com \ X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 18 Apr 2001 11:50:26 -0400 (EDT) From: Polar Humenn To: David Chizmadia cc: csiv2-ftf Subject: Issue 4118 (was Re: Today's (4/18/01) Telecom) In-Reply-To: <002401c0c805$27fc1f00$a000a8c0@davidch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: 'M1e95Ggd9(P7!!L]H!! On Wed, 18 Apr 2001, David Chizmadia wrote: > Don, > > I don't read Ron's counterproposal for 4118 as equivalent to >either > Polar's or mine, but I'm willing to be convinved otherwise. Since >Ron is > out of touch until Monday, it may be better to defer any further > consideration of 4118 until next Wednesday. I agree with David here. I don't think Sun's proposal is equivalent to what we have been dilligently discussing and proposing. Cheers, -Polar > On a separate subject, is there a table anywhere that records the actual > status of the FTF issues? The "official" OMG page appears to be with > respect to the full revision cycle, so I can't tell which issues have been > effectively closed by FTF votes. > > -DMC > > ----- Original Message ----- > From: "Don Flinn" > To: "csiv2-ftf" > Sent: Wednesday, April 18, 2001 8:11 AM > Subject: Today's Telecom > > > > It appears that the telecom's serve the purpose of stimulating e-mail > > discussions as evidenced by the flurry of e-mail this past week. Great > job > > people on resolving 4118! Of course I will have to get a new hard drive > to > > hold the mail :-) but it will be worth it. > > > > The telecom information: > > leader: don flinn > > passcode: 91852 > > conf#: 6670113 > > dial-in#: 712-271-0535 > > # of lines: 10 > > date/time/length: 1/10/-4/25(weekly), 11amEST, 1hr > > > > The discussion items. > > > > Beat up D. Flinn for not getting out the revised write-up to 4200. > > > > Get someone to do the final resolution write-ups on 4118, 4221 for a vote. > > > > Procedure for permanent tabling of issue 3907 for this FTF. I presume that > > this is just a vote to defer. > > > > Ron's resolution for 3906. > > > > Pick the next candidate for e-mail solution. > > > > Don > > > > > > ======================== > > Down the mid-tier > > Over the Firewall > > Nothing but Net > > ======================== > > > > Don Flinn > > Iona Technologies > > don.flinn@iona.com > > Tel: 781-902-8559 > > FAX: 781-902-8001 > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com Date: Tue, 24 Apr 2001 19:08:43 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Polar Humenn CC: Ron Monzillo , jishnu_mukerji@hp.com, David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pa"!!hMC!!LdPe9G2i!! Polar Humenn wrote: > > On Tue, 17 Apr 2001, Ron Monzillo wrote: > > > > > > > Jishnu Mukerji wrote: > > > > > > Polar Humenn wrote: > > > > > > > On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > > > > > > > > > > Good, so we finally have an agreement. Now I hope Ron is OK with this. > > > > I think the current form is > > > > "The privilege_authorities field contains a sequence of zero or more > > ServiceConfiguration elements. A non-empty sequence indicates that the > > target supports the CSS delivery of an AuthorizationToken, which is > > delivered in the EstablishContext message. A CSS shall not be required > > to look beyond the first element of this sequence in determining the > > AuthorizationToken to be delivered." > > > > and David has proposed that the ", which is delivered" phrase be > > removed. I will support the following (including the removal of the ", > > which is delivered" if you desire): > > > > "The privilege_authorities field contains a sequence of zero or more > > ServiceConfiguration elements. A non-empty sequence indicates that the > > target supports the CSS delivery of an AuthorizationToken, which is > > delivered in the EstablishContext message. The first element of the > > privilege_authorities field shall define the AuthorizationToken to be > > delivered." > > What does "define" mean? > I won't insult you by quoting from a dictionary. If you want something to modify define, I will also support "The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. The first element of the privilege_authorities field shall define the determination of the AuthorizationToken to be delivered." X-Originating-IP: [172.166.142.130] Reply-To: polar@syr.edu From: "Polar OnTheRoad" To: Ronald.Monzillo@sun.com, polar@adiron.com Cc: jishnu_mukerji@hp.com, dchizmadia@promia.com, csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types Date: Wed, 25 Apr 2001 15:44:29 -0000 Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 25 Apr 2001 15:44:30.0176 (UTC) FILETIME=[9DC3DE00:01C0CD9E] Content-Type: text/plain; format=flowed X-UIDL: lJk!!k4Rd9mA&e9-<7!! From: Ron Monzillo To: Polar Humenn CC: Ron Monzillo , jishnu_mukerji@hp.com, David Chizmadia , csiv2-ftf@omg.org Subject: Re: Proposed resolution to issue 4118: Multiple Privilege AuthoritiesandSupported Naming Types Date: Tue, 24 Apr 2001 19:08:43 -0400 Polar Humenn wrote: > > On Tue, 17 Apr 2001, Ron Monzillo wrote: > > > > > > > Jishnu Mukerji wrote: > > > > > > Polar Humenn wrote: > > > > > > > On Mon, 16 Apr 2001, Jishnu Mukerji wrote: > > > > > > > > > > Good, so we finally have an agreement. Now I hope Ron is OK with this. > > > > I think the current form is > > > > "The privilege_authorities field contains a sequence of zero or more > > ServiceConfiguration elements. A non-empty sequence indicates that the > > target supports the CSS delivery of an AuthorizationToken, which is > > delivered in the EstablishContext message. A CSS shall not be required > > to look beyond the first element of this sequence in determining the > > AuthorizationToken to be delivered." > > > > and David has proposed that the ", which is delivered" phrase be > > removed. I will support the following (including the removal of the ", > > which is delivered" if you desire): > > > > "The privilege_authorities field contains a sequence of zero or more > > ServiceConfiguration elements. A non-empty sequence indicates that the > > target supports the CSS delivery of an AuthorizationToken, which is > > delivered in the EstablishContext message. The first element of the > > privilege_authorities field shall define the AuthorizationToken to be > > delivered." > > What does "define" mean? > I won't insult you by quoting from a dictionary. If you want something to modify define, I will also support Hoser. "The privilege_authorities field contains a sequence of zero or more ServiceConfiguration elements. A non-empty sequence indicates that the target supports the CSS delivery of an AuthorizationToken, which is delivered in the EstablishContext message. The first element of the privilege_authorities field shall define the determination of the AuthorizationToken to be delivered." I still do not know what define means in this context. If you want to be vague that is your fault. Again, we cannot do anything that you do not want to do, and Don doesn:t want to make into a vote. Don, I suggest taking both of the wordings, put them up to a vote, and let sun be the bad guy and veto things. I:m sorry I didn:t have my friggin dictionary that day. have a nice day. -Polar _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com Date: Fri, 27 Apr 2001 13:43:14 -0400 From: Ron Monzillo X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: David Chizmadia CC: csiv2-ftf Subject: Re: Today's (4/18/01) Telecom References: <000301c0c800$b8611820$2302a8c0@boston.amer.iona.com> <002401c0c805$27fc1f00$a000a8c0@davidch> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: J4*!! > Don, > > I don't read Ron's counterproposal for 4118 as equivalent to either > Polar's or mine, but I'm willing to be convinved otherwise. Since Ron is David, I was not trying to wordsmith the previous proposals. If I had agreed with either of them, I would have accepted them as written. The problem is, I don't agree with either of them. They both have elements of saying we can't do things in the future under the auspices of improving or preserving the level of interoperability that people can achieve today. The best way to ensure the relevance of CSIv2 and thus the profiles for interoperability that can be sustained by its use, is to ensure that we don't burden CSIv2 with requirements that limit it to being only what it is today. The evolution of CSIv2 must preserve existing/planned profiles, but no requirements should be adopted at the expense of future innovation or integration. The best way to handicap CSIv2 is to include requirements in its definition that cause those who might otherwise have adopted it to find its description to be arbitrarily incompatible with their objectives. By saying that the first element must "define the determination of the AuthorizationToken to be delivered", we will have sustained the one-element profile you have been advocating, without arbitrarily limiting the nature of additional profiles (based on new ServiceConfiguration syntaxes). New syntaxes should be available if people want them and are willing to adapt (if necessary) their implementations to support them. Any syntax that requires implementations to be modified, will only be adopted if the value it provides compensates for any (re)implementation pain it causes. Standardizing things like "an implementation shall never be required to look beyond the first element" amounts to writing an entitlement for a specific form of implementation into the specification. Ron > out of touch until Monday, it may be better to defer any further > consideration of 4118 until next Wednesday. > > On a separate subject, is there a table anywhere that records > the actual > status of the FTF issues? The "official" OMG page appears to be > with > respect to the full revision cycle, so I can't tell which issues > have been > effectively closed by FTF votes. > > -DMC > > ----- Original Message ----- > From: "Don Flinn" > To: "csiv2-ftf" > Sent: Wednesday, April 18, 2001 8:11 AM > Subject: Today's Telecom > > > It appears that the telecom's serve the purpose of stimulating > e-mail > > discussions as evidenced by the flurry of e-mail this past week. > Great > job > > people on resolving 4118! Of course I will have to get a new hard > drive > to > > hold the mail :-) but it will be worth it. > > > > The telecom information: > > leader: don flinn > > passcode: 91852 > > conf#: 6670113 > > dial-in#: 712-271-0535 > > # of lines: 10 > > date/time/length: 1/10/-4/25(weekly), 11amEST, 1hr > > > > The discussion items. > > > > Beat up D. Flinn for not getting out the revised write-up to 4200. > > > > Get someone to do the final resolution write-ups on 4118, 4221 for > a vote. > > > > Procedure for permanent tabling of issue 3907 for this FTF. I > presume that > > this is just a vote to defer. > > > > Ron's resolution for 3906. > > > > Pick the next candidate for e-mail solution. > > > > Don > > > > > > ======================== > > Down the mid-tier > > Over the Firewall > > Nothing but Net > > ======================== > > > > Don Flinn > > Iona Technologies > > don.flinn@iona.com > > Tel: 781-902-8559 > > FAX: 781-902-8001 > > > > Reply-To: "David Chizmadia" From: "David Chizmadia" To: "csiv2-ftf" References: <000301c0c800$b8611820$2302a8c0@boston.amer.iona.com> > <002401c0c805$27fc1f00$a000a8c0@davidch> > <3AE9AFB2.1F57D8B1@east.sun.com> Subject: Re: Today's (4/18/01) Telecom Date: Fri, 27 Apr 2001 17:42:41 -0400 Organization: Promia, Inc MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: !:K!!5KM!!KPWd9+~?e9 On Friday, April 27, 2001 1:43 PM, Ron Monzillo wrote: > > David Chizmadia wrote: > > > > Don, > > > > I don't read Ron's counterproposal for 4118 as equivalent to either > > Polar's or mine, but I'm willing to be convinved otherwise. Since Ron is > > David, > > I was not trying to wordsmith the previous proposals. If I had agreed > with either of them, I would have accepted them as written. The problem > is, I don't agree with either of them. A clear statement to that effect would have helped. The context of the message led me to believe that your message was a continuation of the refinements that Polar, Jishnu and myself had been discussing in the later messages of this thread. Silly me. > They both have elements of saying > we can't do things in the future under the auspices of improving or > preserving the level of interoperability that people can achieve > today. Horse puckies! I'm beginning to understand Polar's frustration with you Ron. I disagree VERY strenuously with this statement. I can't figure out whether you chose not to read the complete chain of messages in this thread or whether you disagree on general principle. > The best way to ensure the relevance of CSIv2 and thus the profiles for > interoperability that can be sustained by its use, is to ensure that we > don't burden CSIv2 with requirements that limit it to being only what it > is today. The evolution of CSIv2 must preserve existing/planned > profiles, but no requirements should be adopted at the expense of future > innovation or integration. The words are the result of SUBSTANTIAL discussions (during which you were silent) in which Jishnu drew a line in the sand saying that we should not prevent experimental implementations of multiple-authority servers from interoperating with simple, single-authority clients (and vice versa). Both Polar's proposed wording and my preferred wording ("It shall be possible for the CSS to construct an AuthorizationToken that the target will recognize as valid using only the privilege authority referenced by the first element of the sequence.") are both crafted to allow this. Specifically, they are both completely silent on the issue of multiple elements in the privilege_authorities fields. Their only constraint is that the privilege authority referenced by the first element must be sufficient for acquiring all of the information that the TSS will require in an AuthorizationToken that it will accept as valid. This is NECESSARY to ensure that pre-multi-authority clients will interoperate with any future multi-authority servers. Jishnu, whom many of us to consider to be one of the most reasonable people associated with OMG, agreed that this allowed present interoperability and future evolution. It has always been Polar's (and later my) contention that complete silence is unacceptable. I truly think that these words are a reasonable compromise. > The best way to handicap CSIv2 is to include > requirements in its definition that cause those who might otherwise > have > adopted it to find its description to be arbitrarily incompatible > with > their objectives. This was Jishnu's point exactly and he, Polar, and I believe that any of the proposed words address that issue. Who in Sun is upset with this proposed change and what is their REAL agenda? I've described above how the words explicitly allow innovation, while preserving interoperability. If someone is resisting adoption on *technical* grounds, then the members of this group who are participating in this discussion need to understand their *technical* concerns (preferably with explicit examples of how the spec would prohibit their innovations) so that we can craft the spec more precisely. If it is marketing discomfort or political intrigue, then I guess we'll have to refer the issue to the Board of Directors, which is the appropriate forum for that discussion. > By saying that the first element must "define the determination of the > AuthorizationToken to be delivered", we will have sustained the > one-element profile you have been advocating, without arbitrarily > limiting the nature of additional profiles (based on new > ServiceConfiguration syntaxes). New syntaxes should be available if > people want them and are willing to adapt (if necessary) their > implementations to support them. Any syntax that requires > implementations to be modified, will only be adopted if the value it > provides compensates for any (re)implementation pain it causes. > > Standardizing things like "an implementation shall never be required to > look beyond the first element" amounts to writing an entitlement for a > specific form of implementation into the specification. Misquotation is REALLY annoying. The most recent iterations of Polar's wording say *not* rather than *never*. Which has a completely different sense and allows both minimal and innovative implementations to interoperate - which is after all what CSIv2 is about! But beyond the misquotation, the converse of your statement is that saying nothing amounts to writing an entitlement for a specific *and non-interoperable* implementation into the specification. Given a choice, I'd go with a statement that is true to the first and third words of the name of the specification. But since I don't have veto power, I don't have that choice - bad planning on my part. > > Ron -DMC X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Tue, 1 May 2001 14:14:18 -0400 (EDT) From: Polar Humenn To: Ron Monzillo cc: David Chizmadia , csiv2-ftf Subject: Re: Today's (4/18/01) Telecom In-Reply-To: <3AE9AFB2.1F57D8B1@east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: SBa!!~g4e9-6 > > David Chizmadia wrote: > > > > Don, > > > > I don't read Ron's counterproposal for 4118 as equivalent to >either > > Polar's or mine, but I'm willing to be convinved otherwise. Since >Ron is > > David, > > I was not trying to wordsmith the previous proposals. If I had >agreed > with either of them, I would have accepted them as written. The >problem > is, I don't agree with either of them. They both have elements of >saying > we can't do things in the future under the auspices of improving or > preserving the level of interoperability that people can achieve >today. > > The best way to ensure the relevance of CSIv2 and thus the profiles >for > interoperability that can be sustained by its use, is to ensure that >we > don't burden CSIv2 with requirements that limit it to being only >what it > is today. The evolution of CSIv2 must preserve existing/planned > profiles, but no requirements should be adopted at the expense of >future > innovation or integration. The best way to handicap CSIv2 is to >include > requirements in its definition that cause those who might otherwise >have > adopted it to find its description to be arbitrarily incompatible >with > their objectives. > > By saying that the first element must "define the determination of >the > AuthorizationToken to be delivered", we will have sustained the > one-element profile you have been advocating, without arbitrarily > limiting the nature of additional profiles (based on new > ServiceConfiguration syntaxes). New syntaxes should be available if > people want them and are willing to adapt (if necessary) their > implementations to support them. Any syntax that requires > implementations to be modified, will only be adopted if the value it > provides compensates for any (re)implementation pain it causes. > > Standardizing things like "an implementation shall never be required >to > look beyond the first element" amounts to writing an entitlement for >a > specific form of implementation into the specification. > > Ron > > > out of touch until Monday, it may be better to defer any further > > consideration of 4118 until next Wednesday. > > > > On a separate subject, is there a table anywhere that records >the actual > > status of the FTF issues? The "official" OMG page appears to be >with > > respect to the full revision cycle, so I can't tell which issues >have been > > effectively closed by FTF votes. > > > > -DMC > > > > ----- Original Message ----- > > From: "Don Flinn" > > To: "csiv2-ftf" > > Sent: Wednesday, April 18, 2001 8:11 AM > > Subject: Today's Telecom > > > > > It appears that the telecom's serve the purpose of stimulating >e-mail > > > discussions as evidenced by the flurry of e-mail this past >week. Great > > job > > > people on resolving 4118! Of course I will have to get a new >hard drive > > to > > > hold the mail :-) but it will be worth it. > > > > > > The telecom information: > > > leader: don flinn > > > passcode: 91852 > > > conf#: 6670113 > > > dial-in#: 712-271-0535 > > > # of lines: 10 > > > date/time/length: 1/10/-4/25(weekly), 11amEST, 1hr > > > > > > The discussion items. > > > > > > Beat up D. Flinn for not getting out the revised write-up to >4200. > > > > > > Get someone to do the final resolution write-ups on 4118, 4221 >for a vote. > > > > > > Procedure for permanent tabling of issue 3907 for this FTF. I >presume that > > > this is just a vote to defer. > > > > > > Ron's resolution for 3906. > > > > > > Pick the next candidate for e-mail solution. > > > > > > Don > > > > > > > > > ======================== > > > Down the mid-tier > > > Over the Firewall > > > Nothing but Net > > > ======================== > > > > > > Don Flinn > > > Iona Technologies > > > don.flinn@iona.com > > > Tel: 781-902-8559 > > > FAX: 781-902-8001 > > > > > > > ------------------------------------------------------------------- Polar Humenn Adiron, LLC mailto:polar@adiron.com 2-212 CST Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com > 1. 4118 should be ready for vote > > [1] replace para 148 with the following two paragraphs > > The privilege_authorities field contains a sequence of zero or >more > ServiceConfiguration elements. A non-empty sequence indicates >that the > target supports the CSS delivery of an AuthorizationToken, which >is > delivered in the EstablishContext message. A CSS shall not be >required > to look beyond the first element of this sequence in >determining the > AuthorizationToken to be delivered unless required to do so as a >result > of its support for the ServiceConfiguration syntax of the >first > element. > > The syntax field within the ServiceConfiguration element >identifies the > format used to represent the authority. Two alternative >formats are > currently defined: an ASN.1 encoding of the GeneralNames (as >defined in > [IETF RFC 2459]) which identify a privilege authority, or a >GSS > exported > name (as defined in [IETF RFC 2743] Section 3.2) encoding of >the > name of a privilege authority. >