Namespace idea - nsfw/

[AliceWonder]

I will NOT put any NSFW content in these forums. Ever. I promise. I respect the rights of minors to use this place.
I hope discussion of this idea isn't a nono

But I am thinking about using a nsfw/ namespace

Basically the idea is similar to id/ and u/ in that the key is a unique identifier, but no set standard for what might be in the json string value in the key/value pair.

What I would use it for - certain websites that cater to adults currently only accept credit cards. Many of them hate it, fraud is rampant and there often is censorship on what the sites can do from the credit card processing companies, and those rules are not free speech violations because the processing companies are private businesses, not government.

But they can't accept bitcoin instead because of age verification. With a Credit Card - banking laws do not allow a minor to have a card in their own name, so if the name on the card matches the name on the account then they have been age verified. So there is age verification built in to credit cards that by their very nature, crypto currencies do not have.

My idea is to provide third party age verification through namecoin.

User creates nsfw/handle

User goes to third party and proves they control nsfw/handle by adding a specified key : value to nsfw/handle - provides an e-mail address (which does NOT need to be in nsfw/handle) - and demonstrates they are 21 years of age.

Age verification company then puts sha256sum of handle + email into a database.

User then signs up at adult website specifying their nsfw/handle and the e-mail address used to previously validate their age,

Website creates sha256sum from nsfw/handle and e-mail and asks third party server if the person is age verified. If yes, then website knows it is an adult and can send confirmation code to e-mail, and sell goods/services for bitcoin having made reasonable effort to avoid doing business with minors.

Potentially there could be more than one age verification service and nsfw/handle could contain an array of services that have verified their age, if they want, and an adult website could use any from list that it trusts.

While on the one hand for age verification I could piggyback on id/ or u/ - I think it might be safer for users to force compartmentalization so there is never accidental leakage of their adult activities to IDs they use elsewhere.

e.g. if my boss knows about my id/handle I may not want my boss knowing that I felt a need to verify my age associated with that id/handle.

-=-=-

How I personally would run an age verification business -

1a) If user does not have a nsfw/handle - create one for them. In that case I own it, but would transfer if they wanted it.
1b) If user does have nsfw/handle - they have to prove it is theirs by updating it.

2) I would require scan of .gov issued photo ID (they can black out ID number but not birthdate or address)
3) Utility bill matching name and address (they can black out utility account number)
4) A selfie holding piece of paper with nsfw/handle written on it - so I can verify picture in ID is person in selfie
5) A valid e-mail address

When I validate, I make hash of 'nsfw/handle' + e-mail for database.

If nsfw/handle ever expired in blockchain w/o being renewed then verification hash gets deleted from database.

Simple API for websites - those wanting to know if a user has been validated send hash of 'nsfw/handle' + e-mail and server responds either true or false.

Not foolproof - kid can get his uncle to help him fake the system, but credit card isn't foolproof either, and it demonstrates reasonable effort to verify age that has to be intentionally circumvented to fail, and I suspect that is good enough in most jurisdictions. Especially if RTA header is sent from website that a parent could have used to block access with parental control filter.

It's safer for consumers of adult content because they don't ever have to give financial information away and it is safer for adult websites because bitcoin etc. payments can't be reversed w/o a 51% attack on the blockchain.

And by doing it in namecoin there can be competition for who provides the verification services. Hell, a government itself could even operate an age verification server if they wanted.

I'm going out of town but I'll be putting some code together when I get back and see if I can implement something.

Thoughts?

[John Kenney]

The use is too specific. It'd be better to add verification to id/ entries, then it could be used for other ID verification purposes too.

[signup292]

.

[John Kenney]

Another problem is this is a centralised verification system & therefore untrustworthy. There's no need for Namecoin in this scheme, it could be done just as well without Namecoin & adding Namecoin to the scheme would just be useless overhead for everybody involved.

If you're going to verify ID with Namecoin it should be in a decentralised way that isn't reliant on any single organisation.

[mightbemike]

That's quite a creative idea! I suspect you'll change some things as people give suggestions and criticisms, and you try things out. Personally I wondered about was the age of 21. Why choose that age?

One site operator might want to require a scanned image of government ID, but another might just want you to make the claim that you're a certain age. My suggestion would be to publish a standard for those key-value pairs and hope the client applications find what they want. This will be enabled by having an easy web front end for users to populate these fields, and an API site operators can use to query with.

For example if one site were to require some k/v pairs like:

Code: Select all

nsfw/pchaitaknidsakul
{ "country": "Thailand", "idnum": "67892354833", "idtype": "National ID Card" }  

- OR -

nsfw/fredwilson
{ 
"country": "United States", 
"idnum": "CA47567654",
"idtype": "Driver License", 
"url": "http://flickr.com/983723n234908", 
"sha256": "3c0b5188f50d88621665789b22120a7c153da4000710c4a7291d3a94d1eeb85b"
}

These details can be verified in an automated way. In the first example it's easy for the user to enter the idnum in a form field, and pick the other 2 from dropdowns. Perhaps this info is not sufficient for most NSFW site operators, that's fine.

Scanned IDs are tougher because it seems like the user either needs to send an image to the site operator and have it approved, then insert the hash of it, or insert some URL where it was located. In example 2, the site operator can have a script periodically go grab the image from the user-specified URL and hash it, checking against what was put into the blockchain. User would need to do an update transaction whenever new driver license was issued, scanned in, an hashed again.

I imagine something like above, but more optional fields. The user fills out whatever they want, and the various websites ok or decline them based on whether the info they required was entered by the user.

[biolizard89]

I don't think this should be in a separate namespace, nor should that information necessarily be in the blockchain.

Here's a rough idea for a better way to do it:

Alice is a user who needs to be ID-verified for Bob's service. (This might be for NSFW content, or it might be for the purpose of voting, or it might be to purchase alcohol, etc.) Alice and Bob both trust Carol to provide the ID verification service. Alice gathers the needed documents, and signs them with the "signer" field of her id/alice name. She then sends the signed data to Carol. Carol reviews the documents, and decides that Alice is trustworthy. Carol then creates a JSON message such as the following:

{"name": "id/alice", "maxBirthDate": "1980-01-01T00:00:00Z"}

(The date is in ISO 8601 format.) Carol then signs the JSON message with the "signer" field of her id/carol name. Carol sends this signed JSON to Alice.

Now, Alice can send Carol's signed message to Bob to prove that id/alice was born before Jan 1, 1980, and Alice can use NameID to prove that she controls id/alice.

This scheme is much better in 2 ways. (1) It's more flexible, since it allows any user to vouch for any statement about any other user. (Maybe citizenship is desired in addition to age.) (2) It's more private, since the data isn't accessible to people doing blockchain analysis.

In cases where Alice *wants* a certification to be public knowledge, she can post the signed message from Carol in her id/ name. (She might link to it via "import" if she hits the 520-byte limit.)

All of the above have one important security issue: revocation is not possible. To allow revocation, Carol needs to post the certification in a name that she controls, and link to it from her id/ name. (Carol will need to use "import", otherwise the 520-byte limit will prevent Carol from issuing more than a few certifications.) If Carol needs to revoke the certification, she can simply erase the contents of the certification from the name she controls.

We actually can even allow Carol to issue a nonrevokable certification without changing the protocol from a revokable certification. This requires separate renewal and alteration permissions (which will probably be added to Namecoin soon). To do this, the "alter" script is set to OP_RETURN, and the "renew" script is set to "anyone can spend". By issuing a certification such as this, Carol is agreeing that she will not be able to revoke it later.

Summary: off-chain transactions should be used where privacy is necessary and revocation is not necessary (using the "signer" field and NameID); the id/ namespace should be used otherwise. (We could use a separate namespace from id/ if we wanted, and link to it from an id/ name; this would reduce processing overhead for applications that don't need that data.)

[virtual_master]

2) I would require scan of .gov issued photo ID (they can black out ID number but not birthdate or address)
3) Utility bill matching name and address (they can black out utility account number)

Oh man, this is the worst idea what I ever heard. An ID and bill scan for an adult site ?
Whoever would gather this database could extort a lot of people.
I would suggest a kind of Namecoin passport issued by a certified emitter:
https://forum.namecoin.info/viewtopic.php?f=9&t=1350
The ID check would be in real without digital scan of the IDs, so no danger to misuse them.
This would be a special Namecoin Passport with only age check(only year of birth) so the name and other personal data could be freely elected.
Namecoin Passports could be highly scalable with all entries checked, some entries checked or no entry data checked at all.
Checked entries would be labeled and the signature of the issuer who verified putted in the name entry field.
So who owns a Namecoin Passport with checked age entry by a certified issuer can sign with the private key, which holds the name entry - this part is already solved by Domob with nameid.

[domob]

Thanks for your input - I like it how more and more people get interested in Namecoin and try to use its potential! But I agree with biolizard89's proposal. I think that using id/ is the way to go, together with signed messages via corresponding private keys.

[AliceWonder]

Okay after a lot of thinking -

agev/handle

as a namespace that age verification services could use to identify themselves.

The json string string would include a url of their validation service, a url of a description of their process, and a minimum age.

So say adultmart could choose to offer validation services for any of their customers that have paid with a credit card, and specify that on their description page.

Website A that wants age verification before registering a user, when user joefriday signs up, either via json in his id/joefriday or if he prefers in a field on the registration form, specifies that agev/adultmart is who can authenticate his age.

If Website A has already added agev/adultmart to acceptable age services, they can just send the query. Otherwise, the webmaster can look at the description page and see if adultmart's age validation is acceptable and then add it.

-=-

With respect to my earlier statements about a service looking at ID, for verifying age w/o a credit card processing there really is no other way to make a reasonable effort and with many adult websites, there can be very serious ramifications if the website can't demonstrate they made reasonable effort to validate age. That's why so many use credit cards and won't take crypto-currency, I've had this discussion with several webmasters. Even though a minor could be using a fraudulent credit card, it at least demonstrates reasonable effort to validate age, and bitcoin etc. don't do that.

Webmasters of these sites, for fear of criminal prosecution and very big fines, would only accept validation services that had used a credit card or had seen identification.

[tosh0]

well, while the idea of a government issuing passports on the blockchain is quite far fetched,
it could be possible for an website1, exchange or id verify service to link your data they already have to your nmc identity/address and then allow you to login in other exchange with nameid, then maybe you can download a file from website1 that already has you verified, to website2 and have an api to check if the data is legit. (maybe by signing the file with your nmc identity and the website key?)

so you will be submitting the data to website1 but they don't need anybody to verify it, since it's been verified on website 1.

offtopic: anyway, a way to renew multi-year periods or versioncheck the names is needed.