[OpenID] OpenID and the COPPA

[SitG Admin]

>It appears to me that the Simple Registration Extension would
>qualify as disclosure of the user's personal information, and hence a
>relying party would need some way to confirm a user's age and parental
>permission prior to, or perhaps as part of, allowing an underage user
>to authenticate via OpenID?

I've been giving this more thought. I came up with three ideas for 
how to do it, each of which are flawed in one way or another; these 
ideas are described below, followed by some idle speculation on how 
to repair their flaws.

0) Ask the user to checkmark a "I am at least ## years of age." box 
before submitting URI.

1) Send the user to their Provider for age, then - once they return 
triumphant with credentials - turn them around and send them back 
again to get the rest of the info.

2) Add a "minimum_age" scheme to the Attribute Exchange list, where 
the Provider asserts that this end-user is *at least* that old, but 
does not commit to *exactly* how old. In the Provider, let the user 
select from a drop-down list ranging from newborn to their actual age.

3) As with #2, but with an option for the Consumer to request a 
specific age; the Provider would offer a box to checkmark *only if* 
that user's age was sufficient to meet the Consumer's requirements.

The self-assertion adds another action (mouse-click, navigation to 
that spot) to the process of OpenID login; instead of just entering 
your URI, you have to mouse over a box, click it, and then enter your 
URI. Or perhaps you don't; a Relying Party might be unable to provide 
additional services to underage users, but still be able to provide 
basic services regardless of a user's age. Making this clear adds 
text, which further increases the time taken to authenticate - not 
much more text, if you were already reading the Privacy Policy and 
TOS to begin with, but most users don't do that. If it's not clear 
that what the user desires can be achieved without self-asserting a 
minimum age, or if it IS clear that it can't be, the user may decide 
to checkmark the box anyway - just to proceed. The only aspect of 
this method which recommends itself to me is that it does not require 
any action on the part of a Provider or Consumer at all - no wasted 
bandwidth or processing, just a report to the user that they will 
need to get their parents before continuing (and, even then, they may 
just go right ahead anyway).

The first idea adds to the work done by the Consumer and Provider, 
*and* breaks up the user's authentication process by prompting for 
their username/password (possibly: do they trust this site?), then 
age, THEN the rest of the information.

The second and third ideas would require a Provider to support the 
minimum_age possibility, and (for #3) be able to NOT send users back 
to the Relying Party with a response supplying the personal 
information that Provider *did* support schema for.

All three of these ideas (beyond self-assertion), if implemented in 
the libraries, would (in the rare case of that child genius) require 
some skill to disable; someone using a 3rd-party Provider could lie 
to *that* Provider about their age, and someone hosting their own 
Provider would need to adjust the code slightly to let them lie about 
their age. Except that it is just just young geniuses; some OpenID 
users may live in countries where COPPA (or equivalent laws) do not 
exist, and be irked at having to hack the code just to remove an 
unnecessary part. Whatever changes are made, I propose adding to the 
libraries conditional code, based on something like $coppa=TRUE (by 
default), and with a warning in the comments that disabling it may 
bear legal repercussions in some countries. The purpose of this would 
be to evade any complaint that the OpenID community advertises and 
makes available software which, by default, can violate COPPA or 
similar laws; and to make a reasonable effort to ensure that, if 
anyone changed that area of the code, they were aware of its 
importance.

Sadly, as annoying as #1 is, I currently see it as the best option 
(even though it may not be supported by the specs), because it has 
the advantage of *not* sending any information until the user has 
confirmed their age. Even though the child (and/or parents) may have 
decided to trust the Relying Party with such information, they have 
probably NOT decided to entrust that information to anyone else who 
happens to be sniffing the network - and, if the child's information 
is sent out unencrypted over a wireless connection, the information 
may leak to other people.

-Shade