Two things recently came to mind, and I figure this is a good time to put the two of them together and see if others agree or if I am just a nut job. (My cats would say I am the latter, but what do they know?)

I think there are a couple of items in DirXML Script that could make our lives a lot easier. Let me know if you agree/disagree.

Unique Name token: I wrote an article and had a bit of a discussion at: Unique Name token oddity

The issue is, if you call it, it only searches for the Object class in the current document, OR it searches for the Object class you specify in the token call.

That is useful, but what if you have a container with two or more objects classes stored in it? Say Groups, Users, and I dunno, Workstations. If I want to make a new user based on a pattern of First Initial then Last name, I need to be sure there is not a User, Group, or Workstation with that name.

So to me it seems obvious that the default behavior when no object class is specified is to search all object classes. Then narrow it down, if you specify it. Easy enough fix in the backend.

Secret Store support;
Had a bit of a discussion on this in the Support Forums. Secret store is pretty cool technology, and if you have more than one app using it, really powerful, and hard to replace!!

Basically it stores secrets, securely. iChain, NPS, and Secure Login can all use it. Which means your desktop SSO can integrate with your web SSO via these tools. Excellent!

IDM supports it with a couple of commands, do-set-sso-credentail and do-set-sso-passphrase.

This is great, say some value used as a secret for either login (password), password hint (DOB, SSN, etc), or whatever is changing in your ID Vault, then you have a rule that links it into the Secret Store as it happens.

The problem is, this is push only. I.e. SET. There is no GET.

This means if you want to sync Secret Stores between two trees, there is no way. The attributes are encrypted so raw syncing them will not help. They will not decrypt in the target tree. So if your web SSO is in the Vault or Auth tree (iChain, say), but your desktop SSO (Secure Login)is in the file and print tree, you cannot leverage the information. Not good!

If we had a GET/READ function, we could manage something. Of course, building in the ability to sync the attributes as part of the engine (since the server can decode them...) that would be great too!

What other enhancements do you see IDM/DirXML Script needing? I would exclude for brevity, requests for drivers to currently unsupported connected systems, if you do not mind. I am thinking of things that would be helpful, inside the current model.