where should we store data for future retrieval besides the cookie?

[bnfinet]

No description provided.

[bnfinet]

related to #109

I'd like to document the use cases which we would use and discuss options.

@artagel could you help me to flesh out the thinking here. You've already put quite a bit of good work into #109 but I'm spooked by the lack of iPhone support.

[artagel]

the cookie split is needed no matter what. It'll give a warning, and split cookies if the browse 'does' support it..
with the custom claims support, the claims are an unpredictable size.
so, that is use case #1. You can't control, for example, the size of the 'groups' a user is a member of, which is probably the primary use case for claims.
the second is that passing down access/idtokens, as requested for downstream auth, would inflate the token size(cookie), right now still under 4096 bytes, but pretty close.
so with claims and a combo of the tokens, getting over 4096 bytes is easy. That means storing this in JWT is not correct.

[bnfinet]

how should we support iPhones with custom claims?

Use cases (things we'd like to store and maybe provide to nginx/an app)...

• claims from idP stored in Vouch JWT
• IdP JWT
• logout token
• reauth token

what are we storing and who's going to use it when? Will Vouch Proxy use it to interact with the IdP? Will a VP client (nginx, app) use it?

[bnfinet]

rather than going to an RDBMS, maybe we can provide a mechanism to discover another vouch on your network and then pass data between them using the shared secret.

This seems a bit easier than going full RDBMS and reduces the attack surface.