More on data formats

[Lloyd Hilaiel]

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 [1]
4. if the authority by browserid lookup matches issuer, then trust.  return.
5. else, don’t trust.

lloyd

[1]: https://gist.github.com/callahad/7659759

>  Cheers,
> 
>    Ryan
> _______________________________________________
> Dev-fxacct mailing list
> Dev-fxacct at mozilla.org
> https://mail.mozilla.org/listinfo/dev-fxacct