On 8/05/2015 20:36, Alexis Métaireau wrote:
> On 08/05/2015 00:46, Ryan Kelly wrote:
>> This seems OK at first glance. I'm not sure if there's prior art in the
>> OAuth ecosystem for this. If I understand correctly it's similar to the
>> notion of "bewit" tokens in Hawk, right?
> Yes, it's a similar concept. However, bewit are limited to GET and are
> limited in time [0], which is something that would be too limitant for
> our use case.
Sorry if I missed it in the previous discussion: what is the concrete
use-case for these delegated tokens?
(I'm assuming the "shared music list" service is purely hypothetical
from a Mozilla point of view).
> Also, it seems that this "delegation of authorization" approach also
> means "delegation of authentication", which might be something we don't
> want. For instance, if Alice delegates access to Bob, then Bob actually
> authenticate as Alice. We might have a way to know this is not Alice,
> but we need to be careful with this.
Indeed, this is a thorny issue. There's a saying that "OAuth is for
authorization, not authentication" but it doesn't stop people using it
for authentication all the time.
(It's a bit like "sync is not a backup service" in that regard...)
Perhaps we should add an explicit OpenID Connect layer that *is* for
authentication, and keep the OAuth stuff for proper scope-based
delegated authorization.
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
