Doug, The original design proposed to use "scopes" to access remote namespaces. I still believe that's the most appropriate place to wedge them into the namespace -- profiles don't (currently) have a component in the FMRI namespace, which seems fatal for the remote repository problem. LDAP, as you noted, remains the most credible directory server choice.
Gary, As Doug alludes to, the remote repository project is an SMF project, not a part of Sparks. As far as I'm aware, neither this proposal nor any other recent developments have changed the general points made in our original "DSS requirements" description. (Some of those requirements may be made optional by restricting functionality, but I didn't see new requirements that need to be added.) I don't think this proposal adds any particularly new dimensions to the NSS2 problem. Secret data in the nameservice / directory server is nothing new, even though we weren't considering being an explicit consumer in the past. Schema design for a fully-featured sensitive read/ authorized write repository in the directory server will be something a directoryservice-based repository team will need to deal with. The question of how to actually authenticate to the directory server remains, but is equivalent across both reads and writes. liane
