Subject: [Txauth] brainstorming about "layer session management on top of txauth"

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Mar 2020 15:03:15 -0700

Hi all,

We spent a long time talking about what we mean by identity and what should
be in scope for us to do vs. reuse, and I had an idea that I wanted to get
some feedback on, relating to how we might layer
identity/session-management on top of XYZ.  (I am not sure yet if it would
apply to XAuth or not.)

If we talk about how some of the claims conveyed from AS to client relate
to who the user is, but as Mike notes this starts to look like a "login"
event, and once you have that you want to know about the "logout" event as
well.  Would it be possible to build something that has the client ask for
a resource of "tell me when the user logs out"?  We'd of course need to
define some way to indicate how the AS would convey that to the client, but
on first glance at least it seems like it could work to layer the
session-management on top of claims with semantics like that.  Whether the
resulting set of claims would still look pretty is another matter,
though...

-Ben

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Mar 2020 09:47:08 -0400

I agree that the kind of identity info that we’re looking at Login events are pretty well understood and have been solved with some pretty solid patterns for years. Logout (and session management in general) turns out to be much, much, much harder. I don’t buy the argument that they are required to go together, especially because OIDC was not published with session management and logout functionality. There’s a non-final draft, but it was was last updated 3 years ago and does not have wide adoption. 

Regardless, I think that there is going to be a space to add advanced identity concepts on top of TxAuth — though likely outside of the TxAuth working group, we should design with some of this in mind and leave space and structure for it.

But to spitball an idea on top of XYZ, I think it’s a short step to ask for a session management handle to give to the client. This is an artifact that the AS would know how to dereference to let the client push a “logout” event to the AS. But the client could also, in the same request, register a “logout” callback at the AS, using some variety of mechanisms. So maybe something like this:

{
  "session": {
	"logout_callback": {
	  "url": "https://client.example/logout",
	  "nonce": "0948134"
	}
  }
}

And the server responds with something like:

{
  "session_handle": {
  	"url": "https://server.example/logout",
	"handle": "0948134",
	"type": "bearer"
    }
}

But again, I don’t think that this is necessary for a simple login system or even in scope for TxAuth. Identity is indeed huge, but we don’t need to solve everything in order to solve something universally useful.

 — Justin

> On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi all,
> 
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth