[Openid-specs-fapi] OpenID support for smart tokens
anders.rundgren.net at gmail.com
Fri Jun 22 06:52:09 UTC 2018
On 2018-06-21 20:36, Nat Sakimura wrote:
> Both AccountChooser and OpenYOLO is pretty much client side.
Things are more complex than that. The core issue is really the Same Origin Policy (SOP) that unfortunately is considered close to a law.
However, there are tons of legitimate applications that doesn't work particularly well if constrained by SOP.
Due to that, application writers are toying with all kinds of more or less bizarre workarounds.
Although https://www.accountchooser.com isn't "bizarre", it is indeed a "workaround" using a static domain for emulating the thing that just about everybody need:
a standardized and secure way of communicating
between the Web and the native layer.
Other "famous" tricks include redirects to local services running on 127.0.0.1 which is an non-secure way of accomplishing the above.
To not completely cripple the Web, Google recently introduced a hole in the SOP armor: https://www.w3.org/TR/payment-request/
This mechanism can support smart tokens of the kind I refer to (entirely client based and having full OS access), but limited to payments.
FWIW, I'm currently exploring this facility for arbitrary usage, an unexpected "side-effect" of the poor design by the W3C architects. There was never a need for a hard-coded payment API on the Web! The Web is like an Operating System; it only needs primitives and then various communities like OpenID can create APIs on top of that.
> Sent from Outlook
> for Android <https://aka.ms/ghei36>
> On Thu, Jun 21, 2018 at 3:04 PM +0900, "Anders Rundgren" <anders.rundgren.net at gmail.com <mailto:anders.rundgren.net at gmail.com>> wrote:
> On 2018-06-20 15:28, Nat Sakimura via Openid-specs-fapi wrote:
> > What are smart tokens exactly?
> > Would something like AccountChooser/OpenYOLO help?
> AccountChooser/OpenYOLO seems to be a server-centric way addressing federation issues.
> Smart tokens (in my take NB) are rather client-centric solutions for dealing with federation where the combination of an Authentication key and URL (to the IdP) represent the core. In addition to UX enhancement, such designs may also have "interesting" side effects as shown in this one page presentation: https://cyberphone.github.io/doc/payments/payment-decentralization-scheme-1a.pdf
> > ---
> > Nat Sakimura
> > Research Fellow, Nomura Research Institute
> > Chairman of the Board, OpenID Foundation
> > On 2018-06-14 23:21, Anders Rundgren via Openid-specs-fapi wrote:
> >> Since Tom mentioned "smart tokens" maybe somebody more versed in
> >> OpenID than me could provide me with a pointer to the relevant
> >> specification?
> >> It is obviously not here:
> >> http://openid.net/specs/openid-connect-core-1_0.html
> >> Anders
> >> _______________________________________________
> >> Openid-specs-fapi mailing list
> >> Openid-specs-fapi at lists.openid.net
> >> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
> > _______________________________________________
> > Openid-specs-fapi mailing list
> > Openid-specs-fapi at lists.openid.net
> > http://lists.openid.net/mailman/listinfo/openid-specs-fapi
More information about the Openid-specs-fapi