Signed certificate format: What is the principal?

[dannycoates]

When issuing certificates for FXA, what should the principal be?

As the specs say, the principal is a JSON object that indicates the type of principal, e.g., {"email": "ludmilla@example.com"}.

For FXA certificates, we may wish to issue a principal that contains the unique uid instead, so that it remains the same in the event of the user changing his or her email.

What should this look like?

Related questions include: What concerns for backwards compatibility do we have for existing services (e.g., Marketplace)? What does this do to the verifier? In the future, would we share different information in the principal with third-party apps?

[ckarlof]

Here are some options:

1. principal: { email: <user's real email address>, uid: <firefox accounts uid> }

Cons: FxA is not the IdP for the user's real email, so verifiers need to change to accept these assertions. Reliers need to be informed to not use email as a primary key for the user, because the user could change it (e.g., change the email used to identify themselves with FxA).

2. principal: { email: <firefox accounts uid>@firefox.com, verifiedEmail: <user's real email address> }

Pros: Doesn't require a verifier change - it's BrowserID compliant.
Cons: Awkward, and it's not as-is backwards compatible with what Marketplace is currently doing to identify users (i.e., we're changing the format/meaning of the email field).

I vote for number 1.

[jedp]

I also vote for number 1

[dannycoates]

I went ahead and implemented 1. @rfk r?

[rfk]

Indeed #1 seems most in line with our broader vision of how this service will fit back into the persona ecosystem, as a "secondary identity provider". Opened #292 for implementing the required custom verifier.

r+

[ckarlof]

Love the PR and the closing, but we should probably keep an eye on this discussion: https://groups.google.com/forum/#!topic/mozilla.dev.identity/1ecTUrOFzbQ

[lloyd]

how about principal -> email and uid as a separate property?

[ckarlof]

In the above linked email thread, the consensus seemed to be that since the uid was a property about the principal, it should be an actual JSON property of the principal.

[lloyd]

"The sub value is a case-sensitive string containing a StringOrURI value."

https://groups.google.com/d/msg/mozilla.dev.identity/1ecTUrOFzbQ/OHO6OicRAyMJ

[warner]

I like lloyd's proposal because it includes "fxa" in the name.. it feels like something in this should indicate the firefox-accounts-specificness of the identifier.

And I'm inclined to put "email" outside the main subject or principal object, since our certificate-signer isn't authoritative and isn't really there to make claims about email addresses. I think of the email in these certs as a bit of auxilliary information, rather than the core claim (which is the uid).

[ckarlof]

And I'm inclined to put "email" outside the main subject or principal object, since our certificate-signer isn't authoritative and isn't really there to make claims about email addresses.

I just realized something. It doesn't matter from a backwards compatibility point of view what the future assertion format is for FxA. Our reliers (Marketplace) don't verify them locally. They use the remote verifier. What does matter from a backwards compatibility POV is the remote verifier API. We should probably strive to reduce friction in the Persona -> FxA transition for Marketplace, but we can handle it in the remote verifier API.

So I agree with @warner, let's make this format smell good. sub -> uid in some form and email -> user's email as top level props. Keep it flat: http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

[lloyd]

I agree with the important parts that @ckarlof highlights. But I think there's one more important part. As mozilla we should not create assertions that use the same field for different purposes.

If we change persona assertions to include the email top level property, and for FxA assertions also include another top level property (call it fxa_uuid or sub - don't care), then I'm good, I think chris's concerns are satsified, and I think we conform to the spec.

So +1, but IFF we change persona assertion format to express email using the same property.

[lloyd]

/cc @callahad @fmarier

[djc]

@lloyd, I think I vehemently disagree with your emphasized statement that Mozilla should not create assertions that use the same field for different purposes.

JWT is a standard for signing claims about subjects. IMO if we're going to use that standard, we should try to use it the way it's intended; if we don't, then it would be better to invent a whole different thing to prevent confusion.

If FxA needs to claim things about non-email UIDs, and Persona needs to claim things about email addresses, then it seems perfectly fine to me to have both use the "sub" field in different ways. FxA could use an "email" property to claim that the UID in "sub" corresponds to an account related to that email address.

[lloyd]

(good point dic, took it back to the email list)

On Nov 21, 2013, at 10:15 AM, Dirkjan Ochtman notifications@github.com wrote:

@lloyd, I think I vehemently disagree with your emphasized statement that Mozilla should not create assertions that use the same field for different purposes.

JWT is a standard for signing claims about subjects. IMO if we're going to use that standard, we should try to use it the way it's intended; if we don't, then it would be better to invent a whole different thing to prevent confusion.

If FxA needs to claim things about non-email UIDs, and Persona needs to claim things about email addresses, then it seems perfectly fine to me to have both use the "sub" field in different ways. FxA could use an "email" property to claim that the UID in "sub" corresponds to an account related to that email address.

—
Reply to this email directly or view it on GitHub.

[ckarlof]

We had to revert this because it broke our sync dev effort: 3490257

[ckarlof]

I guess when you turn an issue into a PR, you can't reopen it. :)

[jbonacci]

I assume the reverting happened
here: api-accounts.dev.lcip.org
and
here: api-accounts-latest.dev.lcip.org

[ckarlof]

yes