W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > May 2017

[webrtc-pc] Section 4.2.2

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Wed, 31 May 2017 16:30:46 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-232623747-1496248245-sysbot+gh@w3.org>
aboba has just created a new issue for https://github.com/w3c/webrtc-pc:

== Section 4.2.2 ==
>From EKR: https://lists.w3.org/Archives/Public/public-webrtc/2017May/0166.html

Generally, we try to avoid sharing the same initial keying material
with two hashes, which seems to be explicitly what you propose
here. With that said:

- HMAC already has its own shortening algorithm (you hash)
- You should use HKDF to generate fresh subkeys for each
  hash algorithm.

   Note that the OAuth response "key" parameter is a JSON Web Key (JWK)
   or a JWK encrypted with a JWE format. Also note that this is the only
   OAuth parameter whose value is not used directly, but must be
   extracted from the "k" parameter value from the JWK, which contains
   the needed base64-encoded "mac_key".

It's been a while since I looked at this piece of OAuth, but what
key is this encrypted with?

Why are you requiring that the access token be self-encrypted rather
than (say) a table lookup. This is a reasonable procedure, but it's
not the only one, and not really the standard's business.

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1274 using your GitHub account
Received on Wednesday, 31 May 2017 16:30:53 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:41 UTC