Issue 2027:  PrincipalAuthenticator and Current (sec-rev)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: I have a problem discovering the semantics of using
 Current.set_credentials(SecInvocationCredentials) as opposed to using an
 InvocationCredentials Policy object on Current, or the target object
 reference.
 
 I believe we should deprecate set_credentials and get_credentials infavor
 of InvocationCredentials and NonRepudiationCredentials Policy Objects.
 This mechanism seems more in line with the the way we seem to be
 traveling. So it will be consistent with the client invocation policy
 model. 
 
 Or. we should put an explicit statement ordering the retrieval of
 credentials at object reference creation. 
 
 1. InvocationCredentailsPolicy object off of Target object reference.
 2. InvocationCredentialsPolicy object from the Current.
 3. Current.get_credentials()
 

Resolution: Close issue 2027: Principal Authenticator and Current
Revised Text: We agreed to Remove get/set_credential operations on Current
in favor of the new policy oriented way of setting thread
specific policies.
Page 15-60 Change picture "set_credentials(invocation credentials)"
to ’InvocationCredentialsPolicy".
Replace paragraph 323 on page 15-60 with:
When all required changes have been made the credentials may
be specified as the credentials for all subsequent invocations
by the setting of an InvocationCredentialsPolicy on PolicyCurrent.
Para 345 on page 15-65: Change entire end of paragraph starting with
"Finally it can call Current::set_credentials..." with:Finally, the intermediate object can place the received
credentials in an InvocationCredentialsPolicy for use
in making subsequent invocations.
Para 347. Remove entire end of paragraph starting with "After doing
this, ...." (It’s objective has been stated before, and is overly
stated).
Remove paragraph 349 as we have no idea how this works.
Remove last two bullets of paragraph 568 (set_credentials
and get_credentials).
Remove paragraph 570 talking about set* and get* operations
as they have no significance any more.
Change the initial wording of paragraph 571 by removing the
word "further".
Remove paragraph 579 on page 15-113 through 583 on page 15-114.
(Definintions of get_credentials, set_credentials.)
Appendix A.1: Remove the definition of "enum CredentialType".
beginning with comment "// Credential types which ....."
Appendix A.4: Remove definition of "enum DelegationMode".
Remove the definitions of get/set_credentials on Current.
Actions taken:
October 2, 1998: received issue
April 20, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <polar@adiron.com>
X-Authentication-Warning: marcy.adiron.com: polar owned process doing
-bs
Date: Thu, 1 Oct 1998 18:57:25 -0400 (EDT)
From: Polar Humenn <polar@adiron.com>
To: sec-rev@omg.org, secsig@omg.org
Subject: PrincipalAuthenticator and Current


Good Evening.
Just when you thought it was safe. 

I have a problem discovering the semantics of using
Current.set_credentials(SecInvocationCredentials) as opposed to using
an
InvocationCredentials Policy object on Current, or the target object
reference.

I believe we should deprecate set_credentials and get_credentials
infavor
of InvocationCredentials and NonRepudiationCredentials Policy Objects.
This mechanism seems more in line with the the way we seem to be
traveling. So it will be consistent with the client invocation policy
model. 

Or. we should put an explicit statement ordering the retrieval of
credentials at object reference creation. 

1. InvocationCredentailsPolicy object off of Target object reference.
2. InvocationCredentialsPolicy object from the Current.
3. Current.get_credentials()

Any comments?

-------------------------------------------------------------------
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


X-Authentication-Warning: marcy.adiron.com: polar owned process doing
-bs
Date: Wed, 10 Mar 1999 10:17:47 -0500 (EST)
From: Polar Humenn <polar@adiron.com>
To: Andre Srinivasan <asrinivasan@inprise.com>
cc: sec-rev@omg.org
Subject: Re: Open Issues

On 9 Mar 1999, Andre Srinivasan wrote:

> Issue 2027: I vote to get rid of the policy stuff in Current and
stick 
> with get/set credentials.

This issue is about the PrincipalAuthenticator and Current having two
different ways of setting the credentials object for invocation.

Well, this is a vote for discussion.

We've evolved this policy stuff over time. set and get credentials do
confuse the issue. Also, I think set_credentials is screwed up.

First of all, what happens if you do a get_credentials() before a
set_credentials? If you get a "default" credential, which credential
is
it? Shouldn't this be done by the PrincipalAuthenticator with
appropriate
default values?

Why does set_credentials have a DelegationMode parameter when the
CredentialsType argument may be Non-repudiation type? It doesn't make
sense.

We should discuss more.

-Polar