More on data formats

Chris Karlof ckarlof at
Tue Nov 26 09:54:46 PST 2013

On Nov 26, 2013, at 2:13 AM, Dirkjan Ochtman <dirkjan at> wrote:

> On Tue, Nov 26, 2013 at 10:46 AM, Shane Tomlinson
> <stomlinson at> wrote:
>> On 26/11/2013 02:17, Chris Karlof wrote:
>>> Regarding how we signal the subject of the certificate, here's a summary
>>> of where we're at:
>>> For Persona certificates:
>>> sub: <user's email address>
>>> email: not used
>> Does "email: not used" signify "is not present" or "is preset but
>> undefined"?
> I think the consensus was that it would not be present.

Correct. I apologize for the lack of clarity.

>>> For FxA certificates:
>>> sub: <FxA user id as a uuid>
>>> email: <verified email address supplied by user during signup>
>>> Regarding how we represent the email/uid in the sub, since JWT allows
>>> StringOrURI in the sub, we discussed using URIs to make the implied
>>> semantics more explicit. For example, for FxA certificates, the sub could be
>>> "urn:uuid:<FxA uid>", and for Persona certificates the sub could be
>>> "mailto:<user's email address>".
>> Was any decision made on whether the issuer or URI scheme will be used for a
>> RP to differentiate the two?
> Discussion was mostly around the verifier being able to differentiate,
> not as much the RP, I think. In any case, it seemed to me like people
> were uncomfortable about distinguishing based on the issuer, and
> therefore wanted to add the scheme to make it easier. I must say that
> I still don't fully grasp the perceived issue here.

Crypto/security future feature creep fear. :)

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.


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

More information about the Dev-fxacct mailing list