Create usps.com.yaml

[stuartpb]

Closes #321

[stuartpb]

Not covered in this profile: security question answers are case-insensitive, and require double-blind entry for each of them.

I've saved a specimen of the registration process, but since it's me actually registering for an account at my current mailing address, I'm keeping it on my local disk for reference instead of publishing it (in case there are any unnecessarily-identifying details inside).

[stuartpb]

D'oh, I made a bunch of schema mistakes, I'll fix them later.

[stuartpb]

https://github.com/opws/opws-schemata/blob/master/v0.2/docs/forms.md#multi-identifier-account-inputs notes the mistake I made with form.account, but, honestly, coming back to this a year later, shouldn't they actually be the same field with a single-item accepts array? Having two different kinds of field seems like kind of a legacy detail (even for forms that may have separate email and username inputs, it's still the form "accepting" two kinds of input: I guess the idea was to allow for sites that require email and username? Eugh.)

[stuartpb]

Another thought re: weird schema structure:

I get why mustnot only lives on password.value (because the phrasing of any "mustnot" rule will always pertain to values - here, that values "must not include more than two consecutive identical characters"), but it still feels weird to describe what is ultimately a contents restriction on the value object. (This could probably be described in the documentation, and should probably be debated/reconsidered in an issue on the schemata tracker.)

[stuartpb]

More stray observations about usps.com that don't fit into the current schema:

• Errata: when changing the password, there's a tooltip you can raise listing an unnecessary "special character" requirement, which is not included in the (accurate) description that is also presented on the form, below both password fields. (The tooltip is redundant, in other words, and should have been removed.)
• https://reg.usps.com/login and https://reg.usps.com/register also work for login and registration, but these aren't the URLs consistently used within the current site's links, so I didn't list them. (There's also https://reg.usps.com/portal/login and https://reg.usps.com/portal/register, which are different pages - oh drat, I've made an overcomplicated version of this, hang on.)

[stuartpb]

Okay, to it turns out there's a "normal" version of the Login and Registration pages, and a "portal" version, and I've changed the profile so it points to the "normal" version of each of these.

There are also "clean" (/login) and "raw" (/entreg/LoginAction_input) versions of the URLs: I've gone with the versions that are less likely to change (Cool URIs and all).

[stuartpb]

Another thing I changed in that last commit was replacing the ’ the popups claim is valid in usernames with the ' they actually meant, after testing (on the main registration page) that that was, in fact, what they meant (' does not invalidate usernames).

I kind of figured that's what they meant (especially after seeing the same errata in the Password pop-up), but I figured I'd just double-check to be safe.

[stuartpb]

The other Stray Observation I was going to make before getting sidelined by all this other stuff was that they offer an Account Recovery option if you pair your phone - I'm guessing this just preempts security questions when resetting your password, rather than being a proper second-factor, but either way, I'm gonna try enrolling in it.

It's also maybe worth noting that account setup - for Informed Delivery (the "portal" one), at least - asks for an address and phone number, and then you have to establish your identity either by answering questions from your history, or by having a code physically mailed to you.

[stuartpb]

Okay, once you add your phone, you can "Enable" it for account recovery.

It sounds like they're making the huge mistake of trusting SMS as an overriding authentication factor, so I'm not going to opt into that. Bah, user accounts are such a quagmire.