- From: Peter Beverloo <notifications@github.com>
- Date: Tue, 25 Aug 2015 11:46:14 -0700
- To: w3c/push-api <push-api@noreply.github.com>
- Message-ID: <w3c/push-api/pull/130/r37903344@github.com>
> + <ol> > + <li>Let <var>map</var> be an empty map. > + </li> > + <li>Add an entry to <var>map</var> whose key name is <code>endpoint</code> and whose value > + is the result of converting the <code>endpoint</code> attribute of the > + <a><code>PushSubscription</code></a> to a serialized value. > + </li> > + <li>Let <var>keys</var> be an empty map. > + </li> > + <li>For each identifier <var>i</var> corresponding to keys in internal slots on the > + <a><code>PushSubscription</code></a>, ordered by the name of the key: > + <ol> > + <li>Add an entry to <var>keys</var> whose key name is the name of the key and whose > + value is an <code>ArrayBuffer</code> containing the defined serialization of the public > + key (for an asymmetric key pair) or the key (for a symmetric key). > + </li> I see, thanks! In the interest of not complicating this until we have to, we could, and probably have to define the serialization value per `PushEncryptionKeyName` entry. Since both P-256 and Curve25519 have a 32 octet binary key, this can be done regardless of our decision on the curve, and will remove this ambiguity from the initial PR. The needed complexity can then be added when additional curves get supported. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/push-api/pull/130/files#r37903344
Received on Tuesday, 25 August 2015 18:47:07 UTC