Issue 374: How does get_effective_rights get the delegation state? (sec-rev) Source: (, ) Nature: Clarification Severity: Serious Summary: Summary: Internally in DAPs get_effective_rights [15-131] when turning Cred attributes int0 rights using policy, I need delegation state for each attribute.They don"t contain their delegation state. Resolution: Revised Text: Actions taken: November 18, 1996: received issue March 2, 2001: Deferred:CSIv2 RFP March 22, 2001: moved back to Security RTF Discussion: End of Annotations:===== Return-Path: Date: Tue, 15 Dec 1998 18:16:01 -0500 From: Nick Brachet Organization: Gradient Technologies, Inc. X-Accept-Language: en To: sec-rev@omg.org Subject: Whatever happened to Issue 374? Issue 374: How does get_effective_rights get the delegation state? I don't think it was solved in 1.5? It seems simple enough to add a del_state parameter (like all operation of DomainAccessPolicy). But if it was that simple this issue would have been fixed already... Can anybody shed some light on the problem? -- Nick -- Aintitawfuller! Return-Path: Date: Mon, 21 Dec 1998 13:01:25 -0500 From: Bret Hartman To: Nick Brachet CC: sec-rev@omg.org Subject: Re: Whatever happened to Issue 374? References: <3676EDB0.8F50D22C@gradient.com> Nick, According to my records issue 374 is still open. It was assigned to Bob Blakley eons ago, and Bob had a proposed solution described in the issue 998 archive. The approach doesn't work for multiple credentials, however. Bret Nick Brachet wrote: > > > Issue 374: How does get_effective_rights get the delegation state? > > I don't think it was solved in 1.5? > > It seems simple enough to add a del_state parameter (like all > operation of DomainAccessPolicy). But if it was that simple this > issue > would have been fixed already... > > Can anybody shed some light on the problem? > > -- > Nick -- Aintitawfuller! > > > Nick Brachet > Gradient Technologies, Inc. > [Image] > > Nick Brachet > Gradient Technologies, Inc. > [Image] HTML Mail > 2 Mount Royal Ave Fax: (508) 229-0338 > Marlboro Work: (508) 624-9600 > MA > 01752 > USA > Additional Information: > Last Name Brachet > First Name Nick > Version 2.1 -- Bret Hartman Concept Five Technologies Chief Security Architect 25 Burlington Mall Road hartman@concept5.com Burlington, MA 01803-4141 Voice: 781-229-5308 Fax: 781-229-5346 To: Polar Humenn Cc: sec-rev@omg.org Subject: Re: Open Issues References: From: "Andre Srinivasan" Date: 09 Mar 1999 22:53:04 -0800 Lines: 65 Issue 339: I vote to close Issue 357: I vote to defer Issue 374: Isn't this the same as 998? I think we've made this even more difficult with the addition of ReceivedCredentials (since we no longer even have a chance of seeing the delegation chain). Vote to argue. Issue 375: Its moot whether we took care of this in 1.5. I don't recall the conversation so we need to talk about it again. Issue 379: Already closed Issue 714: Vote to close. We'll get back into this with CSIv2. Issue 716: Already closed Issue 998: Same as 374 Issue 1633: Same as 714 Issue 1723: I vote to accept Polar's picture. Issue 2027: I vote to get rid of the policy stuff in Current and stick with get/set credentials. Issue 2033: I vote to Defer. Issue 2063: I was pretty sure everyone liked Polar's suggestion. We should discuss again. Issue 2069: Need to finish meeting with messaging folks. I vote to defer. Issue 2086: Yuck. Issue 2169: I vote to make the editorial change. Issue 2170: I vote to make the editorial change. Issue 2199: I vote to make the editorial change. Issue 2259: More discussion Issue 2344: I vote to make the editorial change Question: Are nulls *allowed* to be passed to locality constrained y are not for non-locality constrained. I would argue that making that distinction is just asking for trouble. Let's be consistent and stick with the no nulls rule. Besides with the Component/Persistence spec, there's a new IDL modifier for locality constrained objects. Issue 2437: I vote no on Polar's recommendataion. We need to discuss this more. Issue 2440: I vote no on Polar's recommendataion. The credentials that the client sees from the server must come from the object reference. Cool, we need another policy. Issue 2451: We need discussion. Issue 2452: We need discussion. X-Authentication-Warning: marcy.adiron.com: polar owned process doing -bs Date: Wed, 10 Mar 1999 09:59:22 -0500 (EST) From: Polar Humenn To: sec-rev@omg.org Subject: Re: Open Issues On 9 Mar 1999, Andre Srinivasan wrote: > Issue 374: Isn't this the same as 998? I think we've made this even > more difficult with the addition of ReceivedCredentials (since we no > longer even have a chance of seeing the delegation chain). Vote to > argue. I'll agree we need a better model to see the delegation chain, if it exists. However, the list of credentials we had before was a quicky not well thought out solution. It had no integrity. I've seen other misinterpretations for it, being the authentication chain, such as an X.509 certificate chain, which is clearly not the intent. So, we need to think up a scheme for the delegeation chain, and a scheme for the authentication chain. I would conjecture that this move would be better done using an RFP. I would also conjecture that we need a better credentials model all together. ------------------------------------------------------------------- Polar Humenn Adiron, LLC President 2-212 Center for Science & Technology mailto:polar@adiron.com CASE Center/Syracuse University Phone: 315-443-3171 Syracuse, NY 13244-4100 Fax: 315-443-4745 http://www.adiron.com