More on data formats

Brian Warner warner at
Tue Nov 26 15:52:09 PST 2013

On Tue, Nov 26, 2013 at 6:54 PM, Chris Karlof <ckarlof at> wrote:

> It's nice if there is a simple explicit way of knowing how the sub
> field should be interpreted. sub as URI helps with that.

In particular, a BrowserID verifier is going to start with jwt.sub,
treat it as an email, extract the domain, use that to decide what's an
acceptable issuer, check jwt.iss against that list, then fetch the
pubkey from DOMAIN/.well-known/browserid, then check the signature.

The FxA verifier will start with jwt.sub, treat it as a uuid, assert
that jwt.iss equals a baked-in issuer like "", fetch
the pubkey, and check the signature.

If someone submits a different kind of JWT, you want to make sure that a
browserid verifier won't get confused and accept something it shouldn't
(nor should the other kind of verifier accept a browserid JWT).

Any type-indicators we can include (either by putting a URI prefix into
the value of jwt.sub like "fxa-uid:" or "email:" or "browserid:", or
using something other than ".sub") helps us consume a smaller portion of
the "parse tree", leaving more room available for other JWT systems.
When I'm in paranoid crypto-head mode, I use full URLs to make
super-sure that I'm avoiding accidental collisions (I've seen this in
less paranoid arenas too, like RDF tuples and xmlns namespaces).

But there's gotta be a limit where the context determines how you
interpret the contents, and it's easy to go overboard trying to make
everything self-describing (e.g. XML).

> IMO, your proposal is reasonable for the current use cases. 
> I encourage warner to weigh in here.

Yeah, I'm ok with it too. I do kinda think having some kind of FxA
indicator in the assertion (either sub=fxa-uid:UID or using something
other than "sub") would be cheap and would help in the long run, but
it's not something I'd fight a bear over.


More information about the Dev-fxacct mailing list