RE: [higgins-dev] Updating Password with IdAS

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

Yes,  specifically, you can look at the bolded statements that say things like "... is the current proposal" and also see the italicized "Work" items.  The work items should have bugzilla defects assigned where appropriate.  This is the direction I'm moving in.

 

Jim

>>> David Kuehr-McLaren <dkuehrmc@xxxxxxxxxx> 8/30/07 8:09 AM >>>

Jim,

Are you moving forward on Proposal 2 documened on http://wiki.eclipse.org/IdAS_Change_Password ?

David

David Kuehr-McLaren
Tivoli Security - VMM & Tivoli Identity Manager
Identity Integration Architecture
Master Inventor
919.224.1960

"Jim Sermersheim" <jimse@xxxxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx

08/29/2007 07:57 PM

Please respond to
"Higgins \(Trust Framework\) Project developer discussions"        <higgins-dev@xxxxxxxxxxx>

To	"'Higgins (Trust Framework) Project developer discussions'" <higgins-dev@xxxxxxxxxxx>
cc
Subject	RE: [higgins-dev] Updating Password with IdAS

Further refinements have happened to http://wiki.eclipse.org/IdAS_Change_Password 
  
At this point, the proposal is a bit simpler than before. By solving the issue of  being able to update an attribute without first fetching it (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=193226) in a new way, we are able to skip the need to tackle API Extensibility. 
  
I plan to move ahead with the latest direction unless anyone has issues. 
  
Jim

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 8/27/07 9:20 PM >>> 
So, I added this comment which has to do with the API extensibility sub-requirement for password changes to https://bugs.eclipse.org/bugs/show_bug.cgi?id=196390 
/**
* @param method identifies the intended method to be called 
* (such as the Method for IDigitalSubject.addAttribute)
* @param methodArgs the arguments for method
* @param extended args the additional arguments to be sent to the method
*/
public Object extendedOperation (Method method, Object[] methodArgs, Args[]
extendedArgs);


I'm not sure if it would help to make the extendedArgs be of type Args (so we
could make it easy to determine what each arg is using an identifier, as well
as allowing the caller to specify whether the arg must or may be supported by
the CP), or if we should allow any Object. 
Does this seem like a reasonable direction?  Anyone have an opinion on the type we should use for extendedArgs?  I'm coming from a background where Args would be defined to have to properties: 
??? identifier; some globally unique identifier which can be used at runtime to identify the type of the arg, and also could be used to tie the arg to documentation somewhere.  Note that with reflection, this isn't needed (afaik). 
boolean criticality; // true when the caller expects the cp to support this arg (and expects an exception if the cp doesn't support the arg). false when the cp is free to ignore the arg. 
Object payload; // the actual arg. 
  
If we don't need the identifier (which I don't think we do), and don't need the criticality (this _has_ caused some confusion in the world I came from), then extendedArgs could be an Object[]. 
  
Jim 
  

>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 8/24/07 7:38 PM >>> 
Getting back to this after almost a month :( I've added this page that summarizes where we left off. 
 _______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev