Add a list of authentication schemes #262
Conversation
Thanks! I'm a bit in two minds about this. On one hand I can see the value, the implementation cost most likely is low and modulo a few more details it's simple enough.
On the other hand, the property describes capabilities of the push service, not the user agent. Since they can update independently, a UA is now expected to synchronise the available authentication schemes with the push service it has chosen. (Either though an occasional handshake or by aligning release schedules.) That's OK for us, but may not be equally feasible for everyone.
/cc @ShijunS FYI
| @@ -688,6 +689,11 @@ | |||
| when requesting the sending of a <a>push message</a> from the <a>push service</a>. | |||
| </p> | |||
| <p> | |||
| The <dfn data-dfn-for="PushManager">supportedAuthenticationSchemes</dfn> attribute exposes | |||
| the sequence of supported authentication schemes that can be used by <a>applications | |||
There was a problem hiding this comment.
nit: s/applications/application/
| The <dfn data-dfn-for="PushManager">supportedAuthenticationSchemes</dfn> attribute exposes | ||
| the sequence of supported authentication schemes that can be used by <a>applications | ||
| servers</a> to authenticate with the <a>push service</a>. | ||
| </p> |
There was a problem hiding this comment.
Can we list at least "vapid" (and ideally require it -- is that feasible?), but ideally also explain what sort of other values one might expect in this array? Would Chrome include a x-google-gcm or similar if a proprietary mechanism were available?
There was a problem hiding this comment.
Also, does vapid refer to the latest version of the draft, or the previous one (still using Crypto-Key) that still has more implementations?
| "PushSubscriptionOptions">applicationServerKey</a></code> needs to be valid according to | ||
| one of the supported authentication schemes (see <code><a data-link-for= | ||
| "PushManager">supportedAuthenticationSchemes</a></code>). For the "vapid" scheme defined | ||
| in [[!WEBPUSH-VAPID]], the value of <a data-link-for= |
There was a problem hiding this comment.
This now implies that applicationServerKey can contain non-P-256 values too. That creates a conflict in the algorithm at 8.5.2, and makes the paragraph just before this one ambiguous: it mentions an elliptic curve, but what about other sort of values?
|
FWIW, I share your reservations here. |
|
I think that we can abandon this. VAPID is looking to gain support for challenges, which in combination with the change to reject subscriptions if VAPID is required, mostly cover this off. |
We added the ability to discover the content encodings, but more or less forgot to add the supported authentication schemes. This corrects that oversight.