Add parameter to note if client registration should expire

[jricher]

Dynamically registered in-browser public clients are effectively one-time-use and shouldn't outlive their active tokens by very much, if at all. Should we have a parameter that indicates the client is one such thing to allow the auth server to expire the registration at a future point? This would let auth servers clean up after public clients.

[jmandel]

I like this. (I had proposed it for dyn-reg, where it was deemed out of
scope.)
On Jun 20, 2013 1:44 PM, "Justin Richer" [email protected] wrote:

Dynamically registered in-browser public clients are effectively
one-time-use and shouldn't outlive their active tokens by very much, if at
all. Should we have a parameter that indicates the client is one such thing
to allow the auth server to expire the registration at a future point? This
would let auth servers clean up after public clients.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/34
.

[jricher]

I think we have a chance of doing it with BB+ because we've got the six client types that are verifiable by the auth server, the common case of dyn-reg doesn't have that.

[jmandel]

I won't press the point because inclusion in BB+ is all we need right now.
(But in dyn reg more broadly, any client that wants to auto-expire
shouldn't need to have that preference "verifiable" by the server; just
expressing the "expire me" preference really ought to be sufficient.)
On Jun 20, 2013 2:38 PM, "Justin Richer" [email protected] wrote:

I think we have a chance of doing it with BB+ because we've got the six
client types that are verifiable by the auth server, the common case of
dyn-reg doesn't have that.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/34#issuecomment-19785143
.