Signed certificate format: What is the principal? #275
Conversation
Here are some options:
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
Pros: Doesn't require a verifier change - it's BrowserID compliant. I vote for number 1. |
I also vote for number 1 |
I went ahead and implemented 1. @rfk r? |
Use email address as principal in assertion format.
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 |
how about principal -> email and uid as a separate property? |
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. |
"The sub value is a case-sensitive string containing a StringOrURI value." https://groups.google.com/d/msg/mozilla.dev.identity/1ecTUrOFzbQ/OHO6OicRAyMJ |
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). |
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. |
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 So +1, but IFF we change persona assertion format to express email using the same property. |
@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. |
(good point dic, took it back to the email list) On Nov 21, 2013, at 10:15 AM, Dirkjan Ochtman notifications@github.com wrote:
|
We had to revert this because it broke our sync dev effort: 3490257 |
I guess when you turn an issue into a PR, you can't reopen it. :) |
I assume the reverting happened |
yes |
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?