More on data formats
lhilaiel at mozilla.com
Wed Nov 27 01:04:08 PST 2013
On Nov 27, 2013, at 1:59 AM, Ryan Kelly <rfkelly at mozilla.com> wrote:
> On 27/11/2013 10:52 AM, Brian Warner wrote:
>> On Tue, Nov 26, 2013 at 6:54 PM, Chris Karlof <ckarlof at mozilla.com> 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 "accounts.firefox.com", 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 
4. if the authority by browserid lookup matches issuer, then trust. return.
5. else, don’t trust.
> Dev-fxacct mailing list
> Dev-fxacct at mozilla.org
More information about the Dev-fxacct