 |
 |
OK, there is a lot of stuff going on here. So, let's go through what zrn was supposed to be for and what it seems people want it to do.
If you go back to the original discussion, we wanted to know that a client connecting to a server was capable of getting valid tokens. That's all. We didn't care who that was, what they were going to do, or anything else. All we cared about is showing proof of capability.
This is why it was implemented the way it was. The token only needs to be validated. We don't need any generated acls. All we need is that the token is for the acceptable audience issued by a known token issuer. Period, nothing more. That's why we never saved that token.
Now, it seems people want feature creep and want access to the token "just in case". We can do that by using the standard mechanism of placing the token in the creds field of the SecEntity structure and I would strongly resist any other approach as this is the standard way X509, Krb5 and other credential protocols do. As for exposure due to a core file, the token has an expiration date and hopefully these tokens are issued with a reasonably short lifetime so by the time the core file is exposed to unauthorized people (which would have a lot of other security implications outside of SciTokens), the token would have expired. So, I don't see this as very serious concern beyond exposing a core file no matter what.
So, my understanding that all that is wanted is to be able to access the ztn token in the case that a request does not have a url token. This, of course, runs in the face of narrow tokens and we might get stuck with fat tokens which is counter to what everyone wants. So, I don't see how this will play well in the future.
Have I missed something here?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.
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