* 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
