On 12/05/2015 07:56, Ryan Kelly wrote: > On 8/05/2015 20:36, Alexis Métaireau wrote: Sorry if I missed it in > the previous discussion: what is the concrete use-case for these > delegated tokens?
We don't currently have any use case for this, but I foresee this is something you might want to do with a generic backend: share permissions with no-fxa users. For daybed, we used this extensively and it was useful in a variety of cases [0]. That being said, I believe we should put this aside for now and focus on the payments uses case we've got. > 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. If OAuth is for authorization, then we're okay in that regard I believe, but for storage, we're using the bearer token as a proof of identity as well. Shouldn't we? > (It's a bit like "sync is not a backup service" in that regard...) Wait, what? sync is not a backup service? ;) > Perhaps we should add an explicit OpenID Connect layer that *is* > for authentication, and keep the OAuth stuff for proper > scope-based delegated authorization. I'm not sure what that would mean in terms of workflow? [0] http://js.daybed.io/ -- Alexis. GPG Key — 0x95E3C667D1CFA3CE
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
