Last Comment Bug 794634 - Handle unverified emails from persona login
: Handle unverified emails from persona login
Product: Marketplace
Classification: Server Software
Component: Consumer Pages (show other bugs)
: 1.0
: x86 Mac OS X
P1 normal (vote)
: 2013-01-17
Assigned To: Christopher Van Wiemeersch [:cvan]
Depends on: 811014 823736
Blocks: marketplace-payments 805608 809971 824720
  Show dependency treegraph
Reported: 2012-09-26 14:39 PDT by Kumar McMillan [:kumar] (needinfo all the things)
Modified: 2013-01-14 12:03 PST (History)
14 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Kumar McMillan [:kumar] (needinfo all the things) 2012-09-26 14:39:01 PDT
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.
Comment 1 User image Kumar McMillan [:kumar] (needinfo all the things) 2012-09-26 14:40:57 PDT
Dan, is there a spec for this yet we can work towards?
Comment 2 User image Ben Adida [:benadida] 2012-09-27 12:48:12 PDT
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".
Comment 3 User image Wil Clouser [:clouserw] 2012-10-02 10:04:58 PDT
JR is checking this out.
Comment 4 User image JR Conlin [:jrconlin,:jconlin] 2012-10-02 11:10:08 PDT
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.
Comment 5 User image Wil Clouser [:clouserw] 2012-10-02 12:59:08 PDT
We're going to revisit this next week after Ben has a chance to finish the spec.  We did some notes here:
Comment 6 User image Wil Clouser [:clouserw] 2012-10-15 10:25:06 PDT
No spec as of yet.  Ben thinks there will be very minor changes to the marketplace.
Comment 7 User image JR Conlin [:jrconlin,:jconlin] 2012-10-22 16:29:55 PDT
Is there a spec finalized for this yet? (Or at least a draft i can start working against?)
Comment 8 User image Wil Clouser [:clouserw] 2012-10-23 12:58:26 PDT
Just talked with Ben.  No spec yet, anticipated delivery date is Nov 6th.
Comment 9 User image Austin King [:ozten] 2012-11-01 11:44:12 PDT
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
Comment 10 User image Wil Clouser [:clouserw] 2012-11-01 11:50:31 PDT
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.
Comment 11 User image Kumar McMillan [:kumar] (needinfo all the things) 2012-11-01 12:02:02 PDT
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 ?
Comment 12 User image Austin King [:ozten] 2012-11-01 12:04:52 PDT
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.
Comment 13 User image JR Conlin [:jrconlin,:jconlin] 2012-11-01 16:04:19 PDT
(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.
Comment 14 User image Jason Smith [:jsmith] 2012-11-06 13:53:28 PST
Not on-device - removing nom.
Comment 15 User image JR Conlin [:jrconlin,:jconlin] 2012-11-08 13:33:54 PST
patch ready but pending
Comment 16 User image Wil Clouser [:clouserw] 2012-11-30 09:11:10 PST
(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?
Comment 17 User image Kumar McMillan [:kumar] (needinfo all the things) 2012-12-18 12:38:15 PST
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.
Comment 18 User image Wil Clouser [:clouserw] 2012-12-18 14:32:46 PST
Putting in this milestone, but could slip since we're midweek.
Comment 19 User image Christopher Van Wiemeersch [:cvan] 2012-12-27 09:20:54 PST
Comment 20 User image Austin King [:ozten] 2013-01-14 11:26:17 PST
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.
Comment 21 User image Kumar McMillan [:kumar] (needinfo all the things) 2013-01-14 11:30:54 PST
Whoops, cvan can you fix this? To test it, try forcing the wrong issuer to make sure the assertion fails then put it back.
Comment 22 User image Christopher Van Wiemeersch [:cvan] 2013-01-14 12:03:55 PST

Note You need to log in before you can comment on or make changes to this bug.