My recommendation, like the others, is to store consent by
client_id:user and then try and leverage dynamic client registration if
instance level consent is needed.
On 1/27/16 11:43 AM, George Fletcher wrote:
Yes, I was thinking mostly of "native apps"... though you bring up a
good point. It would be great if "installable" web apps could do
dynamic client registration:) I suppose for a "public" client that is
loaded onto a device, the "installation" process could obtain a new
client_id for that instance. Cookies might work, or have the app
generate a unique identifier and use that in conjunction with the
client_id?
Thanks,
George
On 1/27/16 11:07 AM, Thomas Broyer wrote:
On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
The difference might be whether you want to store the scope
consent by client "instance" vs client_id application "class".
Correct me if I'm wrong but this only makes sense for "native apps",
not for web apps, right?
(of course, now with "installable web apps" –e.g. progressive web
apps–, lines get blurry; any suggestion how you'd do it then? cookies?)
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
