I2IM Conference Call May 14, 2003

*Attendees*
Klaas Wierenga, SURFnet
Rob Banz, U. Maryland, Baltimore County
Nadim El-Khoury, UNC
John Paul Robinson, UAB
Neal McBurnett, Internet2
Jeanette Fielden, Internet2
Steve Olshansky, Internet2

*Discussion*

The Internet2 Spring Member Meeting BoF was well attended and focused on bringing those new to I2IM up to speed.

John Paul sent an e-mail to the I2IM list about the auth/Z cases. It appears that regardless of who is doing the query, the two scenarios break down into a pre-staged attribute query and an on-the-fly attribute query. The pre-staged query is less dynamic. It involves getting an attribute at the start when you connect to the XMPP network. The XMPP network can do nothing but release all those attributes to everybody that wants them. If you go the other route of just getting attributes when you need them, you could have an identifier for who is querying for these attributes, and just release the ones you want to release to that entity. Is it possible to combine the two scenarios that Peter sent out so you could have the dynamic nature but not have to have the complexity in the individual services? Couldn’t the originating XMPP server provide some kind of more dynamic service if it somehow already knows that some attribute or authorization request is coming in?

Should that be client be controllable or left to the administrator as an enterprise wide decision? It is an organizational issue and depends on who has the authority to make that decision. It is more of a consideration down the road once people are comfortable with federated trust. When there is a proper way to describe the social networks that are developing, that’s when people will understand what it means to release attributes about yourself to other entities. You don’t give just anyone your driver’s license number.

The scenarios being described transcend the IM environment. IM can be viewed as one particular transport of a communication that requires pseudonymity. John Paul is interested in using Shibboleth like interactions for anonymous features with UNIX shell accounts, where you wouldn’t care what the account name was on the machine as long as you have access to the shell. A simple scenario would be a one-time use shell that you use without any expectation that you would bind to a pre-existing shell account. Another scenario would be returning to a shell session and needing some way of pre-identifying the shell without knowing the account name.

Neal indicated that this sounds like managing access to resources. Traditionally a shell provides access to CPU time, disk space etc. In the Grid world those things are separated out and access to resources in the grid environment is a proxy approach with a job scheduler acting on behalf a user. John Paul indicated that the Grid map file comes into play, and the old UNIX account definition is mapped to the Grid identity. A scenario might be where you want to use cycles on a machine but are trying to reduce overhead in provisioning an account.

John Paul felt that casting it as an IM shell on a remote account might be an easier way to describe the relationship that he is trying to identify rather than involving Grid issues. If this were an IM service what would the needs be as opposed to a traditional UNIX shell? What elements of the use cases are generic end-point interaction elements that transcend any particular technology and implementation issues? John Paul will continue to work on describing it.

r as an enterprise wide decision? It is an organizational issue and depends on who has the authority to make that decision. It is more of a consideration down the road once people are comfortable with federated trust. When there is a proper way to describe the social networks that are developing, that’s when people will understand what it means to release attributes about yourself to other entities. You don’t give just anyone your driver’s license number.

The scenarios being described transcend the IM environment. IM can be viewed as one particular transport of a communication that requires pseudonymity. John Paul is interested in using Shibboleth like interactions for anonymous features with UNIX shell accounts, where you wouldn’t care what the account name was on the machine as long as you have access to the shell. A simple scenario would be a one-time use shell that you use without any expectation that you would bind to a pre-existing shell account. Another scenario would be returning to a shell session and needing some way of pre-identifying the shell without knowing the account name.

Neal indicated that this sounds like managing access to resources. Traditionally a shell provides access to CPU time, disk space etc. In the Grid world those things are separated out and access to resources in the grid environment is a proxy approach with a job scheduler acting on behalf a user. John Paul indicated that the Grid map file comes into play, and the old UNIX account definition is mapped to the Grid identity. A scenario might be where you want to use cycles on a machine but are trying to reduce overhead in provisioning an account.

John Paul felt that casting it as an IM shell on a remote account might be an easier way to describe the relationship that he is trying to identify rather than involving Grid issues. If this were an IM service what would the needs be as opposed to a traditional UNIX shell? What elements of the use cases are generic end-point interaction elements that transcend any particular technology and implementation issues? John Paul will continue to work on describing it.