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

From: Mike Jones <[email-masked]>
Date: Tue, 24 Mar 2020 19:12:39 +0000

I agree that there has to be a space for advanced (and simple) identity concepts on top of TxAuth, including logged-in sessions, which can be refreshed through ongoing use and can be logged out.  Answering Ben's question, I agree that there would need to be a way to layer "tell me when the user wants to log out" notifications.  As Justin says, and as we learned from the SAML experience, different use cases may require different such kinds of notifications, for instance, some over the front channel and some in the back channel.  Both the SAML and OpenID Connect experiences provide data points that there's not a one-size-fits-all logout mechanism on the Web as we know it today.

The same kind of layering should also apply to login.  Some authorization requests are also authentication (login) requests and some are not.  There needs to be a clear mechanism in the request for indicating which is which.  OpenID Connect signaled that the authorization request was also to perform a login by including an "openid" scope value.  Other syntaxes would also be fine.

The key point is that, if the TxAuth requests and responses are extensible, it should be possible to define both the login and logout syntaxes and semantics using these extension mechanisms - probably in distinct specifications from the TxAuth core.  TxAuth can be designed with these possibilities in mind but that doesn't mean that there's a compelling argument to include them the core spec.

Paraphrasing Ben, it should be straightforward to "layer identity management on top of txauth".

				-- Mike

-----Original Message-----
From: Txauth <[email-masked]> On Behalf Of Justin Richer
Sent: Tuesday, March 24, 2020 6:47 AM
To: Benjamin Kaduk <[email-masked]>
Cc: [email-masked]
Subject: Re: [Txauth] brainstorming about "layer session management on top of txauth"

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,
> 
> 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
> 
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/txauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 24 Mar 2020 15:17:22 -0400

I agree that identity claims probably shouldn’t be in the core spec and have said as much many times. That doesn’t put them out of scope of the working group, or conversely make them deliverable at the same time as the core protocol. I have even written the charter text to cater to that flexibility in enumerating the deliverables for identity separately. 

 - Justin

> On Mar 24, 2020, at 3:12 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Dick Hardt <[email-masked]>
Date: Wed, 25 Mar 2020 10:55:39 -0700

We had a short thread on this list of using TxAuth to bootstrap a session
management protocol.

For example, the AS could return a Session URI that the Client could poll
using SecEvent to receive and send security events about the user to/from
the AS.

I would not expect TxAuth to reinvent SecEvent, but it including a URI for
the Client to use in the response looks like a useful integration point.

On Tue, Mar 24, 2020 at 12:17 PM Justin Richer <[email-masked]> wrote:

> I agree that identity claims probably shouldn’t be in the core spec and
> have said as much many times. That doesn’t put them out of scope of the
> working group, or conversely make them deliverable at the same time as the
> core protocol. I have even written the charter text to cater to that
> flexibility in enumerating the deliverables for identity separately.
>
>  - Justin
>
> > I agree that there has to be a space for advanced (and simple) identity
> concepts on top of TxAuth, including logged-in sessions, which can be
> refreshed through ongoing use and can be logged out.  Answering Ben's
> question, I agree that there would need to be a way to layer "tell me when
> the user wants to log out" notifications.  As Justin says, and as we
> learned from the SAML experience, different use cases may require different
> such kinds of notifications, for instance, some over the front channel and
> some in the back channel.  Both the SAML and OpenID Connect experiences
> provide data points that there's not a one-size-fits-all logout mechanism
> on the Web as we know it today.
> >
> > The same kind of layering should also apply to login.  Some
> authorization requests are also authentication (login) requests and some
> are not.  There needs to be a clear mechanism in the request for indicating
> which is which.  OpenID Connect signaled that the authorization request was
> also to perform a login by including an "openid" scope value.  Other
> syntaxes would also be fine.
> >
> > The key point is that, if the TxAuth requests and responses are
> extensible, it should be possible to define both the login and logout
> syntaxes and semantics using these extension mechanisms - probably in
> distinct specifications from the TxAuth core.  TxAuth can be designed with
> these possibilities in mind but that doesn't mean that there's a compelling
> argument to include them the core spec.
> >
> > 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": {
> > 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
> >

---

From: Justin Richer <[email-masked]>
Date: Wed, 25 Mar 2020 17:11:07 -0400

And I think “using TxAuth to bootstrap a protocol” is the right way to look at how this protocol will fit in the wider world. TxAuth can be the basis for a LOT of different things, even more than OAuth is the basis for a lot of things. We can discuss these kinds of protocols and be aware of them as we’re designing, b ut that doesn’t mean we need to be the ones to hammer out all of the details of things like sessions.

Getting the identifier for the current user for login purposes is such an incredibly common use case that I still think it should be in scope for us to handle in the group -- but limited to just that kind of thing, and in my opinion probably in a secondary document once the group is choosing where to put content. 

 — Justin

> On Mar 25, 2020, at 1:55 PM, Dick Hardt <[email-masked]> wrote:
> 
> We had a short thread on this list of using TxAuth to bootstrap a session management protocol.
> 
> For example, the AS could return a Session URI that the Client could poll using SecEvent to receive and send security events about the user to/from the AS. 
> 
> I would not expect TxAuth to reinvent SecEvent, but it including a URI for the Client to use in the response looks like a useful integration point.
> 
> 
> 
> On Tue, Mar 24, 2020 at 12:17 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> > On Mar 24, 2020, at 3:12 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > From: Txauth <[email-masked] <mailto:[email-masked]>> On Behalf Of Justin Richer
> > To: Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
> > Cc: [email-masked] <mailto:[email-masked]>
> >         "url": "https://client.example/logout <https://client.example/logout>",
> >         "nonce": "0948134"
> >       }
> >  }
> > }
> > 
> >       "url": "https://server.example/logout <https://server.example/logout>",
> >       "handle": "0948134",
> >       "type": "bearer"
> >    }
> > }
> > 
> >> On Mar 23, 2020, at 6:03 PM, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> Hi all,
> >> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> > 
> > --
> > Txauth mailing list
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>