- 需求的场景描述（希望解决的问题）          我们既然提供了web-view组件，就应该首先解决父子组件的通信问题，这个问题一直被大家诟病，但我们强大的微信团队是否出于某种考虑，限制了很多通信功能，我目前在集成认证体系时发现，目前的方式很难满足我的需求，我的用户token有多个（了解标准oidc你就会知道），而且每个都是jwt，会很长，再加上用户本身的头像等信息，url传参基本不现实。为何不对web-view开放wx.getStorage接口呢，本身来说h5页面获取小程序的信息做业务逻辑是合乎常理的！ - 希望提供的能力     如题，望给予回复

- 需求的场景描述（希望解决的问题） 小程序登录本来是想采用oauth2.0做授权吗？作为一个主体，UnionID才是我们想要的，而我们的登录流程只能获取到OpenID，我们自定义登录态是要跟UnionID绑定，或者我们用户体系需要跟UnionID做绑定。但遗憾的是，登录态都已经返回了，我们才有可能拿到UnionID 此接口改变了oauth2.0的实现，让我们的用户体系很难跟小程序集成。小程序考虑到自己实现的逻辑和页面合理，却没有考虑各个主体与微信用户绑定关系难实现的问题。 如果UnionID是通过前端获得，再去与我们的用户体系建立关系，本身存在安全漏洞，我们也不知道如何去实现这种绑定，更主要的问题是我们需要用UnionID建立绑定关系，而不是OpenID。 - 希望提供的能力 希望小程序能把UnionID在流程的更早阶段获得，这样我们也好返回自定义的登录态

- 需求的场景描述（希望解决的问题） 虽然开发者希望借助微信的流量衍生自己的产品，但是，微信最重要的社交属性却没有发挥很大的作用，很多小程序看似很好的点子，但因为缺乏社交性质导致流量越来越小，最后无人问津。说实话小程序的运营很难，流量基本走下坡路，或者只火一时，或者只能是工具，需要的时候用一下，缺乏粘性。 - 希望提供的能力 用户选择自己的好友，但是组件或API只提供OpenId和UnionID，我们需要将排名等社交属性运用起来。 我们想开发一个小程序，用户选择好友，但是好友也选择他的时候，两者就建立友好地关系。但目前用户选择不了他的好友。