Expiry on STREAM credentials

[adrianhopebailie]

There is currently no way to explicitly "expire" a set of STREAM credentials (the ILP Address and Shared Secret that the client uses to connect to the server).

This is a problem because technically they need to then be valid indefinitely which makes accounting for payments against specific connections difficult to do.

The simplest way to solve this seems to be simply adding an error code that the server can return to tell the client that the credentials have expired.

E.g. 0x0A Connection Expired

If a client attempts to connect using expired credentials then the server can immediately respond with a CloseConnection frame and the new error code (0x0A).

The server may also send a CloseConnection frame and the new error code (0x0A) at any time after a connection has been established.

The expected behaviour is for the client to notify the calling application that the connection has expired and that it should perform setup again to get new credentials.

In the Web Monetization use case this would involve the sender making a new call to the Payment Pointer URL using the same requestId as before. This should return new credentials but the server should continue to associate incoming payments on the new connection with the same requestId.

How a server tracks the expiry of credentials is left to the implementation. To do this across a distributed set of receivers it would likely be encoded into the address.

[emschwartz]

Why isn't this part of the application layer protocol? It seems like expiry might be important for some applications but not for others.

[sharafian]

Currently Web Monetization never reuses STREAM credentials. Right now we expect them to always expire after one use, and you could set a cache control header to keep them around for longer

[adrianhopebailie]

Why isn't this part of the application layer protocol? It seems like expiry might be important for some applications but not for others.

It is. But that means it needs to know that a connection can be closed and not re-opened at the transport layer.

Currently Web Monetization never reuses STREAM credentials. Right now we expect them to always expire after one use, and you could set a cache control header to keep them around for longer

But that assumption is not enforced at the transport protocol layer. If a client starts sending on a connection that the server considers closed what should happen?

[adrianhopebailie]

@emschwartz @matdehaast @sappenin @sharafian any further feedback on this?

What is the correct behaviour of a STREAM receiver if it receives an incoming connection using old credentials?

What is the expected validity of credentials?

[sappenin]

There is currently no way to explicitly "expire" a set of STREAM credentials

For security reasons, it seems best to treat Credentials Expired and Invalid Credentials as the same. In either case, the server shouldn't be using the credentials, so returning encrypted frames at all shouldn't be happening.

What is the correct behaviour of a STREAM receiver if it receives an incoming connection using old credentials?

Return an ILPv4 Reject packet with an F06: Unexpected Payment code and an optional error message. The credentials are no longer valid, so the server shouldn't be using them.

[emschwartz]

It seems like in order for this to be built into an application, you would need:

• A hook for the application protocol logic to catch incoming STREAM connections and decide whether to accept or reject them
• To decide on an error code to use in this case (since it's an application layer concern, 0x09 Application Error seems like it would fit)
• Persistence for the STREAM connection details (something that probably should not be built into the transport implementation but may make sense to have for specific applications, as those applications probably already require persistence)

What is the correct behaviour of a STREAM receiver if it receives an incoming connection using old credentials?

STREAM has no concept of credential expiry, so I wouldn't expect it to have any special behavior to handle this.

As discussed in other conversations about what should be in/out of STREAM, my general questions are:

• will the vast majority of applications built on STREAM require the exact same feature? (seems like the answer is some but not all)
• is this something that the transport layer has more knowledge about or for some reason is the only part of the stack that has access to the information necessary to make a certain decision? (don't think that's the case here unless providing the initial hook I mentioned would be very onerous)

[sappenin]

The consensus from the ILP community call here is:

• The F06 error-code at the STREAM/ILPv4 layer is sufficient for this use-case (i.e., no need to explicitly add something new to STREAM itself).
• The SPSP response could return the credentials expiry to aid the sender in knowing how long credentials should live.
• STREAM receiver implementations could encode the credential expiry into the ILP destination address so that a stateless STREAM receiver will be able to derive this value from the ILP address.

[adrianhopebailie]

Also, we need to do some experiments to see how this could/should be added to the interface from the app layer down to the STREAM implementation.

Some ideas:

• The STREAM implementation has a default expiry so whenever the app asks for new credentials it knows they will expire in X minutes
• The function to request credentials has a new optional param to express the expiry required
• The return value of the function to request credentials also returns the expiry

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is important, please feel free to bring it up on the next Interledger Community Group Call or in the Gitter chat.