* denis walker via db-wg
then we can get even more flexible if the LIR portal allows you to define set names for lists of SSO auths. So instead of just flagging a contact to be included in 'the' list of expanded SSO auths, you can add a csl of list names in the portal. Then you can have all your contacts defined in any combination of multiple lists that you choose.
eg, Person 1 | List1,List3 Person 2 | List1 Person 3 | List2 Person 4 | List1, List2 Person 5 | List3
then define the new auth as auth: SSO-LIR no.foobar.List3 which will be automatically expanded to those contacts defined as being in List3
This would certainly solve my problem too (especially if there's an implicit «all» group available), but I am somewhat worried about feature creep here, as this would require changes / new features in the RIPE NCC Access / LIR Portal applications. My original proposal would only require reading information already stored in those applications. I'm not in a position to estimate the amount of additional work needed for this, just keep in mind the saying «perfect is the enemy of good». Tore