Closed Bug 794634 Opened 11 years ago Closed 11 years ago

Handle unverified emails from persona login


(Marketplace Graveyard :: Consumer Pages, defect, P1)



(Not tracked)



(Reporter: kumar, Assigned: cvan)



When a user first logs in to the Marketplace on a phone they might be using an unverified email. Marketplace should parse this email and mark the account as *unverified*. At some future date, the user may log in with the same email but it will be verified.

This feature is not yet implemented in Persona but will be soon. There are some details to work out so check with Dan Mills on those details.

Here is an *example* of what would happen to illustrate (but it's not yet final). A user will log in and Persona will return an assertion to Marketplace with an email like Marketplace will parse the real email and use that instead of the alias. Later on, we might see so we'll need to merge accounts or treat them as one.

The reason we want to mark accounts as unverified is so that we can restrict certain actions. We might want to restrict PIN resets to verified accounts, for example.
Dan, is there a spec for this yet we can work towards?
Priority: -- → P1
Kumar: details TBD, but high-level:

- you'll get an assertion

- you'll hit the verifier and get a data structure that looks much like the current one, except with the field "unverified-email" instead of "email".
blocking-basecamp: --- → +
JR is checking this out.
Assignee: nobody → jrconlin
Target Milestone: --- → 2012-10-04
A few additional questions:

1. How will these unverified addresses be submitted to (Can I create "" to upload my free "Exploit my Phone!" app?

2. Validators other than will not be able to validate or provide these, right?

3. Will the "unverified-email" be the "unescaped" email address (E.g.

4. Should unverified email address expire?

5. Will there be other unvalidated email providers.

I'd strongly recommend that unverified assertions containing a previously verified address be rejected as invalid.
We're going to revisit this next week after Ben has a chance to finish the spec.  We did some notes here:
Target Milestone: 2012-10-04 → 2012-10-11
No spec as of yet.  Ben thinks there will be very minor changes to the marketplace.
Target Milestone: 2012-10-11 → 2012-10-25
Is there a spec finalized for this yet? (Or at least a draft i can start working against?)
Just talked with Ben.  No spec yet, anticipated delivery date is Nov 6th.
Whiteboard: [needs spec]
Target Milestone: 2012-10-25 → 2012-11-15
Whiteboard: [needs spec] → [needs spec][spec ETA 11/6]
Blocks: 805608
Blocks: basecamp-id
No longer blocks: basecamp-id
Changes by area:

# Marketplace (Relying Party)
Instead of;

use{issuer: '', allowUnverified: true});

# Remote Verification:

Instead of a POST to with parameters assertion and audience, use

a POST to with parameters allowUnverified, issuer, assertion, and audience.

Note: allowUnverified is optional and MUST match the value used in the call for this user flow. It is a boolean and defaults to false.

Note: issuer is optional in the general case but required for the b2g UA. It should be set to The general case being Android Marketplace users, or the web.

If allowUnverified=true is used, the JSON encoded response body will have either email or unverified-email, to signal if this was an unverified Identity Assertion.

If allowUnverified=false or is not included in the request, only the email property is possible for successful verifications.

If issuer is used, the UA will ignore primary IdPs, so will be authenticated against even if is a BrowserID Primary IdP.

# Local Verification:
A local verifier should follow the beta1 id-spec[1] with the following additions:

7. If the Relying Party is using the optional unverifiedEmail argument to, then they SHOULD expect the principal to be either an unverified-email or email.
7.1 For a specific Identity, if the RP had previously accepted a verified Backed Identity Assertion, then it MUST NOT accept an unverified Assertion (Bug#805608)
7.2 Using the optional unverifiedEmail SHOULD accept an unverified-email as a success case and SHOULD continue to treat the identity as untrusted in the rest of 
 their business logic.

Your call if you want to do remote or local verification. We'll support either.

It's best to put the issuer ( and the verifier hostname into config as some bikeshedding may occur.

[1] Assertion Verification of
Thanks Austin.  JR - can you have a look and see if that jives?  We can do some vidyo or email with Austin if there are questions.
Whiteboard: [needs spec][spec ETA 11/6]
Thanks ozten. This sounds good. In the case of Android/desktop though, can we still verify assertions against ? Or do we need to make a special case for these non-B2G requests and use ?
Yes, in the case of Android/desktop you can we still verify assertions against

You will only include audience and assertion as parameters to it.
(In reply to Kumar McMillan [:kumar] from comment #11)

Looks fairly straight forward and there's enough detail to work with. 
I'll ping ozten if there's any issues with getting this running.
Not on-device - removing nom.
blocking-basecamp: + → ---
Blocks: 809971
Depends on: 811014
Target Milestone: 2012-11-15 → 2012-11-22
(In reply to JR Conlin [:jrconlin,:jconlin] from comment #15)
> patch ready but pending

That patch was pulled in.  What's the status of this bug?
JR says:
"Ignore the reformatting, assertion and quoting spoo and you get you'll get the meat of the patch."

It needs a rebase and a merge but otherwise should be ready to go.
Putting in this milestone, but could slip since we're midweek.
Assignee: jrconlin → cvan
Target Milestone: 2012-11-22 → 2012-12-20
Target Milestone: 2012-12-20 → 2012-12-27
Blocks: 824720
Closed: 11 years ago
Resolution: --- → FIXED
I apologize that Comment#9 is out of date.

All references to "issuer" should be changed to "forceIssuer".

So the request parameter is forceIssuer. The verifier query string parameter is also forceIssuer.
Whoops, cvan can you fix this? To test it, try forcing the wrong issuer to make sure the assertion fails then put it back.
Resolution: FIXED → ---
Target Milestone: 2012-12-27 → 2013-01-17
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.