RE: [provision] SPML identifier issues for the interop ...

["Jeff Bohren" <jbohren@opennetwork.com>]

I'm not sure about the other vendors, but for our product the problem is two-fold. First the identifier should be unique for it to be a valid add request. Secondly, the uid (or login id) should also be unique so if the user wants to see that he can use his supplied uid/password combination to access a protected web site, or login into our User Management web application, it will work.
 
I suppect that the other vendors would have similar problems if two add requests are made with the same uid. Would either user then be able to log into their product? Or would only one be able to log in? This would be an error in our product, even if the identifiers are unique. 
 
Jeff Bohren
OpenNetwork Technologies

	-----Original Message----- 
	From: Yoav Kirsch [mailto:Yoav.Kirsch@businesslayers.com] 
	Sent: Wed 6/11/2003 6:56 PM 
	To: 'Cohen, Doron '; Jeff Bohren; 'provision@lists.oasis-open.org ' 
	Cc: 
	Subject: RE: [provision] SPML identifier issues for the interop ...
	
	

	 This should be the RA responsibity if the RA send the indentifier. For the
	interop we should assume that the RA will create a unique identifier either
	by using People Soft ID or by custom code writen on the RA
	Yoav
	
	-----Original Message-----
	From: Cohen, Doron
	To: Jeff Bohren; provision@lists.oasis-open.org
	Sent: 6/11/03 5:33 PM
	Subject: RE: [provision] SPML identifier issues for the interop ...
	
	Wouldn't it be fair to assume that PSFT has a unique identifier for
	employee that can be used (since the HR system itself needs to
	distinguish between two employees with the same name) ? 
	
	-----Original Message-----
	From: Jeff Bohren [mailto:jbohren@opennetwork.com]
	Sent: Wednesday, June 11, 2003 11:11 PM
	To: provision@lists.oasis-open.org
	Subject: RE: [provision] SPML identifier issues for the interop ...
	
	
	
	The problem is what if two users named John Smith both use the common
	RA. For the first one there is no problem. For the second one, a request
	will be made to add a user with the GUID of an already existing user.
	For our system that is an error and the second add request will fail.
	Since we are not supporting status, the second user won't know why his
	user ID/password combination that he entered will not allow him to log
	onto our system.
	
	Now I could add special logic to make true GUID out of the GUID passed
	to our system to get around this, but since all of the PSPs should have
	similar issues, it makes sense to solve this in one place (the common
	RA). Can the common RA be configured to make sure that the CN is not
	reused? It would probably be a good idea to make sure the uid is not
	reused as well, if possible. We could also set the GUID id to the uid
	instead of the CN and just make sure that the uid is unique.
	
	BTW, if you think having two CNs the same is unlikely, what if one user
	wants to run through the demo twice from two different vendors?
	
	Jeff Bohren
	Product Architect
	OpenNetwork Technologies, Inc
	
	
	-----Original Message-----
	From: Kevin Boyce [mailto:kevin.boyce@entrust.com]
	Sent: Wednesday, June 11, 2003 3:56 PM
	To: Jeff Bohren; provision@lists.oasis-open.org
	Subject: RE: [provision] SPML identifier issues for the interop ...
	
	
	it would be nice if the RA generated unique ids for the duration of the
	demo but since we are not supporting status or any other requests for
	the interop, it should not functionally matter
	
	-----Original Message-----
	From: Jeff Bohren [mailto:jbohren@opennetwork.com]
	Sent: June 11, 2003 12:59 PM
	To: provision@lists.oasis-open.org
	Subject: [provision] SPML identifier issues for the interop ...
	
	
	For the interop we are using the SPML add request where the identifier
	is specified. Therefor the RA must ensure that the specified identifier
	is unique. In the examples in the interop spec the GUID identifier type
	is used with the user's CN as the guid. Obviously the CN is not
	guaranteed to be unique. I would suggest that we either use the email
	identifier (would require users to enter their real email) or we use the
	GUID identifier with an autogenerated GUID.
	
	Jeff Bohren
	Product Architect
	OpenNetwork Technologies, Inc
	
	
	
	
	You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php