You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Hi Andy,
my understanding of the vomsxrd code was that (if the "all" option is used) it should arrange each single field (VO, group, role) as a space-separated list from which the tuples could be reconstructed.
That's rather ugly, but it might have been done due to the API being as it is.
Here's the part from the code:
https://github.com/gganis/vomsxrd/blob/d4e18738331af0c905ce16ed99f634d102931585/src/XrdSecgsiVOMSFun.cc#L261-L275
So, are you proposing to chnage the VOMSFun to supply at attribute list of n-tuples? Are we actually structuring attributes that way with out certs today?
Yes, that would be my expectation. I think all VOMS proxies are structured like this.
For example, my very own VOMS proxy contains:
attribute : /atlas/de/Role=production/Capability=NULL
attribute : /atlas/de/Role=NULL/Capability=NULL
attribute : /atlas/Role=NULL/Capability=NULL
(which I used in the last post as example) and the one I have shown in the first post was also a "real" proxy used by an FTS.
Of course, if that's the diretion we want to go in, wouldn't it be better to simply switch to the WLCG identity tokens?
I am not sure we are there yet - we probably need a way to parse VOMS attributes correctly before.
Cheers,
Oliver
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1