[freaky friday] assertion verification gone wild
lhilaiel at mozilla.com
Mon Nov 25 13:58:53 PST 2013
On Nov 23, 2013, at 6:29 PM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> 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.
Ok. I can do that.
>> 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.
Agree with this. That variable name is a lie.
>> 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.
i’ll have more to say about this. In my previous response I explained how loosey goosey the current verifier is. Would we want to first stand up the “v1” backwards compatibility api and subsequently create a much more stringent api for the future?
More information about the Dev-fxacct