More on data formats

Lloyd Hilaiel lhilaiel at
Wed Nov 27 01:04:08 PST 2013

On Nov 27, 2013, at 1:59 AM, Ryan Kelly <rfkelly at> wrote:

> On 27/11/2013 10:52 AM, Brian Warner wrote:
>> 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.
> My understanding was that we hoped the distinction between "BrowserID
> Verifier" and "FxA Verifier" would go away, and leave us with a single
> instance of "The Verifier".
> Is this still a goal, and does the proposed assertion format make it
> easier or harder?

That is still my goal.  If everyone used the `email` field to assert emails it would make the job easier and cleaner. 

The conclusion reached recently is that we should use `sub` for email for persona because that’s the semantic intent of the JWT spec.

With recent decision (sub is email for persona, sub is uuid for fxa), the verifier will:
1. see if the issuer is trusted by the caller, if so, then trust.  return. (firefox accounts)
2. if not, extract the sub field
3. if the sub field is a valid email, extract the domain and lookup authority [1]
4. if the authority by browserid lookup matches issuer, then trust.  return.
5. else, don’t trust.



>  Cheers,
>    Ryan
> _______________________________________________
> Dev-fxacct mailing list
> Dev-fxacct at

More information about the Dev-fxacct mailing list