[freaky friday] assertion verification gone wild

Dirkjan Ochtman dirkjan at ochtman.nl
Sat Nov 23 08:29:17 PST 2013

On Fri, Nov 22, 2013 at 5:36 PM, Lloyd Hilaiel <lhilaiel at mozilla.com> wrote:
> So I set out to write a local verification library in node.js that has full parity with our existing hosted verifier, but is completely standalone.  My criteria for success was to be able to provide only the domain of the fallback as a parameter and be able to discover all configuration via the browserid protocol.

Having a self-contained verifier seems like a big improvement. Having
good validation of our usage of jwcrypto, possibly even more so.

> 1. support extended idp claims (needed for FxA and to support features like unverified-email, also desired by our payswarm friends)
> results: https://github.com/lloyd/browserid-local-verify/blob/8b51f42/tests/idp-claims.js
> 2. extended rp claims (wanted by our webrtc brethren)
> (supported but not yet tested, return object includes uaClaims object)

For both of these, it would be *really* helpful to have a little .md
document showing some examples of what you're doing here. Tracing
through test code, browserid-local-verify and jwcrypto to see what
choices you made here is a little harder than it should be, IMO.

> Here are the questions that I have:
> a. how does the API feel?  - https://github.com/lloyd/browserid-local-verify/blob/8b51f42/README.md

The API seems pretty good.

> b. How do folks feel about IdP claims extraction: https://github.com/lloyd/browserid-local-verify/blob/8b51f42e/lib/verify.js#L31-L58

Looks pretty good, although maybe I wouldn't call that constant
jwtRegisteredClaimNames if there's a bunch of non-JWT stuff in there.

> c. How do folks feel about secondary support?  (client expresses an array of trustedIssuers, #0 above)

Seems about right.

> d. How do folks feel about the non-standard support document in our fallback and the required gyrations to deal with it: https://github.com/lloyd/browserid-local-verify/commit/8b51f42e

Looks like that's being dealt with.

As I'm trying to help a user on IRC who's currently debugging a 502
Bad Gateway from the verifier, we should be trying really hard to send
good error messages. Some things we've been trying:

- GET /verify returns 404 (should probably throw 405 instead)
- Should the audience include the scheme? The port?
- What about non-urlencoded data sent as x-www-form-urlencoded? (Like
- What about internationalized domains?

The verifier API endpoint should really be extremely defensive.



More information about the Dev-fxacct mailing list