概述
该提案为地址助手URL新增了认证机制。
动机
地址助手URL本质上是不安全的。任何人都可以在链接中放置一个地址助手参数，甚至是图片中，并可以在 “i2paddresshelper” URL参数中放置任何目的地。根据用户的HTTP代理实现，这种主机名/目的地映射，如果当前未在地址簿中，可能会被接受，无论是否有用户接受的中介页面。
设计
可信的跳跃服务器和地址簿注册服务将提供添加认证参数的新地址助手链接。新增的两个参数将是一个base 64签名和一个签名者字符串。
这些服务将生成并提供一个公钥证书。这个证书将可供下载并包含在http代理软件中。用户和软件开发人员通过包含证书来决定是否信任这些服务。
在遇到地址助手链接时，http代理将检查额外的认证参数，并尝试验证签名。验证成功后，代理将如往常一样继续，或者接受新条目或向用户展示中介页面。若验证失败，代理可拒绝该地址助手或向用户显示额外信息。
如果没有认证参数，http代理可以接受、拒绝，或向用户呈现信息。
跳跃服务将像往常一样被信任，但增加了一步认证。其他网站上的地址助手链接需要被修改。
安全影响
该提案通过来自可信注册/跳跃服务的认证增加了安全性。
规格
待定。
两个新参数可能是i2paddresshelpersig和i2paddresshelpersigner？
接受的签名类型待定。可能不是RSA，因为base 64签名会很长。
签名算法：待定。也许只是hostname=b64dest（与提案112中用于注册认证的相同）
可能的第三个新参数：注册认证字符串（在"#!“之后的部分），由HTTP代理用于额外验证。字符串中的任何”#“必须转义为”#“或”#"，或替换为其他指定（待定）的URL安全字符。
迁移
不支持新认证参数的旧HTTP代理会忽略它们，并将其传递给网络服务器，这应该是无害的。
可选地支持认证参数的新HTTP代理可与不包含认证参数的旧地址助手链接正常工作。
要求认证参数的新HTTP代理将不允许不包含它们的旧地址助手链接。
代理实现的策略可能会在迁移期逐渐演进。
问题
站点所有者无法为自己的网站生成地址助手，因为它需要来自可信跳跃服务器的签名。他必须在可信服务器上注册，并从该服务器获取认证过的助手URL。站点是否有办法生成自认证的地址助手URL？
或者，代理可以检查地址助手请求的引荐来源。如果引荐来源存在，包含b32，并且b32与助手的目的地匹配，则可以作为自我推荐被允许。否则可以被视为第三方请求并被拒绝。